transfer cft installation guide unix - docs.axway.com
TRANSCRIPT
Transfer CFTVersion 3.3.26 December 2021
Installation Guide Unix
Copyright © 2018 Axway
All rights reserved.
This documentation describes the following Axway AMPLIFY software:
Transfer CFT 3.3.2
No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.
This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.
Axway recognizes the rights of the holders of all trademarks used in its publications.
The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.
Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.
Contents
Preface 1About Transfer CFT 1Installation guide outline 1Who should read this guide 2Transfer CFT documentation set 2Support services 2
Accessibility 3Accessibility features of the documentation 3Screen reader support 3Support for high contrast and accessible use of colors 3
1 Prerequisites 5Overview 5License keys 5End User License Agreement 6Check your authorization 6
System requirements 7Supported operating systems and browsers 7Disk space and RAM requirements 7Java 7Installer screen resolution 7GUI mode requirement 8
UNIX specific requirements 8Using installer on HP-UX 11i 9
Customize the kernel 10About kernel customization 10Why customize the kernel? 11HP-UX: Customize the kernel 12Linux: Customize the kernel 13Solaris: Customize the kernel 15
Default ports 17Certificates 18Shared file system prerequisites 18Standalone installation 18Active/passive cluster 18Active/active cluster 18
Transfer CFT 3.3.2 Installation Guide 3
2 Install 20Before you start 20Installation package contents 20Installation functions 20Installation modes 20Installed directories 21System language setting 21
Start the installation 21Cluster mode screens 26Auto import (for migration) 27Multi-node options 28Governance options 30Connector options 30Cluster installations 32Silent mode installation 37
Active/active installation 41Commands 41Troubleshooting 42Shared file system prerequisites 42
Install active/passive - Unix 48Prerequisites 48Install 49Shared file system prerequisites 50
Installer functions 55Installer functions 55JRE customization 58
3 Post installation 61Verify your installation 61Installed directories 61
Register with Central Governance 61Start Copilot 61
Verify the Transfer CFT registration with Central Governance 61Log in to Central Governance 61Start Transfer CFT server 62View log using Central Governance 62
4 Update, upgrade, or migrate 63Start here: Upgrade, update, and migration 63Updates versus upgrade or migrate 63Update or upgrade using Central Governance 65Important information 65
Determine the installer and product versions 65Update Transfer CFT 67
Transfer CFT 3.3.2 Installation Guide 4
Download the update file 67Check product details 67Impacted directories when updating a product 67Use Central Governance for updates 67Install a standard update 68Uninstall an update 68Install patches and service packs in a multi-node, multiple host environment 69
Upgrade Transfer CFT 70About upgrades 70Before you start 70Use Central Governance to upgrade Transfer CFT 70Upgrade Transfer CFT 2.6.4 to 3.3.2 71Upgrade Transfer CFT 2.7.1 to 3.3.2 74Upgrade Transfer CFT 3.0.1 to 3.3.2 77Upgrade Transfer CFT 3.1.x to 3.3.2 79Upgrade Transfer CFT 3.2.x to 3.3.2 80Post upgrade 81
Upgrade a Transfer CFT multi-node installation 82Before you start 82Upgrade Transfer CFT 3.0.1 multi-node to 3.3.2 83Upgrade Transfer CFT 3.1.3 or 3.2.4 multi-node to 3.3.2 85Managing multi-node 87Post upgrade 88Check the new version 88Uninstall an upgrade pack 88
How to free disk space from service packs 88Use the purge command 88
Perform a standard migration 89Migration prerequisites 89Install and auto import 90Migrating from Transfer CFT 2.3.2 to 3.3.2 94Migrating from Transfer CFT 2.4 to 3.3.2 97Migrate from Transfer CFT 2.5 or 2.6 to 3.3.2 101Migrating Transfer CFT 2.6.4 SP2 or 2.7 to 3.3.2 104Migrating Transfer CFT 3.0.1 or 3.1.x to 3.3.2 106Migrating Transfer CFT 3.2.x to 3.3.2 110
Activate Central Governance connectivity 116Overview 116Automatically activate connectivity 116Manually activate connectivity 117Connect to a different Central Governance system 120Use former configuration objects 120View managed features 120
Post-migration procedure 121
Transfer CFT 3.3.2 Installation Guide 5
Post manual migration or auto import 121Post-manual migration only 122Post upgrade 122
5 Uninstall 123
6 Troubleshooting 125Troubleshoot installation and registration 125Copilot server issues 125Central Governance 125Transfer CFT server 126
Apply a license key 126Obtain a license key 127Apply a license key 127About command 128
Support tools /contact Support 128Accessing the Axway Support site 128Using cft_support 129
UNIX: Core dump recommendations 130
7 Unix operations 131Running Transfer CFT for the first time UNIX 131Set the environment 131Start and stop commands 132Start or stop via a user interface 133Automatic Transfer CFT start on system start up 133Configure systemd services 137Running CFTUTIL 139Declaring additional users 140Connecting to the Copilot server - UNIX 143Using system users UNIX 145Switching procedure 148Processing accounting files 150Suffix management 152Transfer CFT temporary files 153Client/server variable additions 156Transfer CFT user interface 156UNIX-specific unified configuration options 156Define additional environment variables 159
About Transfer CFT utilities 160Overview 160Management utilities 162Transfer CFT control utilities 167System utilities 171
Transfer CFT 3.3.2 Installation Guide 6
About API applications 175Development kit contents 176Creating an API application 176Creating an exit file 177Creating a directory exit 178Creating an accounting exit 181
UNIX High Availability 182About AIX and IBM HACMP 182About Solaris Sun cluster 185Specific Transfer CFT configurations 197
Deployment packages 201Create a product deployment package 201Install a template Transfer CFT 201Generate the Express Package 202Customize the Express Package 203Install the Express Package 204Limitations 205
Transfer CFT 3.3.2 Installation Guide 7
Preface
This documentation provides information to aide you in installing, updating, upgrading, or migrating Transfer CFT.
About Transfer CFTTransfer CFT is the file transfer component in the Axway Managed File Transfer solution, and provides a multi-platform, high-volume, file and message transfer service. This documentation explains how to install, configure, and manage Transfer CFT.
Using version 3.1.x or higher, you can configure Transfer CFT and manage flows using Axway Central Governance. Central Governance simplifies Transfer CFT usage, and provides services such as identity and access management, certificate management, monitoring, alerting, and a web dashboard.
For more information on Axway products, visit www.axway.com.
Installation guide outlineThis guide explains how to perform a full installation of Transfer CFT. It also describes how to:
Prepare and plan your installation – Describes what you should plan for deploying and configuring your system architecture, installing any prerequisite software, and configuring other components.
Install – Describes how to perform a complete install as well as apply a service pack.
Post installation – Provides instructions on how to check if the installation was successful and set up Transfer CFT. Additionally it describes any tasks to perform before the administrator can log on to the product for initial configuration.
Upgrade – Involves a change in product version and the replacement of binary artifacts; may also require configuration change.
Migrate– Involves a change in product versions, such as from 2.7.1 to 3.3.2. As part of this process, the existing configuration may need to be modified or updated to be compatible with the new version. For example, you may need to modify configuration files or the internal datafile schema. Because migration can be a complex process, organizations typically set up a migration project to study the new features and determine the impact on the existing configuration, and to plan for the changes across the various environments.
Uninstall – Describes how you can uninstall Transfer CFT.
Transfer CFT 3.3.2 Installation Guide 1
Preface
ExpressPackage - Describes how to create a product package that you can deploy to multiple remote sites.
Troubleshoot the installation or registration process – Describes the different types of troubleshooting errors you can encounter during installation, upgrade and post-installation.
Who should read this guideThis guide is intended for enterprise personnel involved in installing software and Axway Professional Services personnel. Familiarity with AMPLIFY products is recommended.
This guide presumes you have knowledge of:
l Your company’s business processes and practices
l Your company’s hardware, software, and IT policies
l The Internet, including use of a browser
Others who may find parts of this guide useful include network or systems administrators and other technical or business users.
Transfer CFT documentation setTransfer CFT provides a complete set of documentation, covering all aspects of using the product. These documents include the following:
l Transfer CFT 3.3.2 Release Notes
l Transfer CFT 3.3.2 User Guide (HTML)
l Transfer CFT 3.3.2 Local Administration User Guide
l AMPLIFY Supported Platforms Guide
l AMPLIFY Interoperability Matrix
Support servicesThe Axway Global Support team provides worldwide 24 x 7 support, subject to validation of your license agreement. Email [email protected] or, for your local support telephone number, visit support.axway.com and click Contact Axway Support.
Transfer CFT 3.3.2 Installation Guide 2
Accessibility
At Axway, we strive to create accessible products and documentation for all of our users.
This section describes the accessibility features of the documentation.
Accessibility features of the documentationThe product documentation provides the following accessibility features:
l Screen reader support
l Support for high contrast and accessible use of colors
Screen reader support l Alternative text is provided for images whenever necessary.
l The PDF documents are tagged to provide a logical reading order.
Support for high contrast and accessible use of colors l The documentation can be used in high-contrast mode.
l There is sufficient contrast between the text and the background color.
Transfer CFT 3.3.2 Installation Guide 3
Accessibility
4 Installation Guide Transfer CFT 3.3.2
1 Prerequisites
OverviewAxway products are delivered electronically from Sphere, the Axway support website. A welcome letter notifies you that your products are ready for download.
To install you will perform the following tasks:
1. Check your license key and authorization.
2. Check the hardware and system requirements.
3. Download product.
4. Install products.
License keys Before installing or upgrading, make sure you have obtained a license for Transfer CFT. Check that the license key is correct for the features and operating system you intend to install. It is not mandatory to enter the license key during the Transfer CFT installation, but you do require a key to start the product.
For information on applying a license key post installation, or if you have a problem with your license key, refer to the appropriate Troubleshooting topic. Depending on your OS, see:
l Windows: Applying license key
l UNIX: Applying a license key
l z/OS Applying a license key
l IBM i Applying a license key
Multi-node license keysTransfer CFT in a multi-node architecture requires:
l One key per node, and if there is more than one host you require at least one valid key per host
l Each key must have the cluster option
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use a single key for multiple hosts, either:
Transfer CFT 3.3.2 Installation Guide 5
1 Prerequisites
l The hostname must not be defined for the key, or
l The hostname defined for the key matches the hostname of one of the hosts that composes the multi-node instance
Additionally, the key must have the cluster option.
Example
If you have 2 hosts and 4 nodes, you require 4 keys with at least one key per host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to reference to the second host
Transfer CFT in a multi-node architecture requires a shared file system for use of a multi-node architecture on several hosts (active/active). Additionally, the system must be configured prior to the multi-node installation, and the shared disk ready when starting the Copilot server.
l Windows only: You must map the shared disk to a drive letter. Windows UNC is not supported.
l Windows only: The Copilot Service Mode cannot be started as the LocalSystem account.
l Windows only: If you are running Copilot in Service Mode, you must set up a dependency with the shared disk's service for multi-node.
End User License AgreementYou should read and accept the End User License Agreement (EULA) prior to installing Transfer CFT. The EULA file is in the directory where you decompressed the Transfer CFT package.
Check your authorizationVerify that you can access Axway support at support.axway.com and log in. If you do not have an account, follow the instructions in your welcome letter.
Log in to download or access:
l The product installation package
l Your product license key
l Product documentation
l Product updates, including patches and service packs
l Product announcements
l Axway Supported Platforms Guide
l The case center, to open a new case or to track opened cases
Transfer CFT 3.3.2 Installation Guide 6
1 Prerequisites
System requirementsThe following are the system requirements for Transfer CFT.
Supported operating systems and browsersRefer to the Axway Supported Platforms Guide for more information.
Disk space and RAM requirementsTransfer CFT has the following hardware requirements:
l Disk space requirement
o 1.5 to 5 Gigabyte: minimum disk space to allow for future updates, SPs, and continued performance
l RAM Requirement
o 128 Megabyte: minimum dedicated per host
JavaThe Transfer CFT Copilot client is based on Java technology. To avoid compatibility issues Axway provides the correct JRE, which is installed during the product installation in the <Axway home>/java/<platform name>/jreX directory, where jreX represents the Java version.
Clients that connect to Copilot require Java 8. If you intend to implement EBICS (UNIX/Windows) or Secure Relay you also require Java 8.
Java 8 is delivered with the product, with the following exceptions:
l Java 7: linux-s390-32, linux-s390-64, sun-sparc-32, sun-x86-32
l Java 6: hpux-parisc-32, hpux-parisc-64, linux-ia64-64
Secure Relay Java installation directory prerequisite
When using Secure Relay, Java must be installed in the same environment as the Transfer CFT installation. The Master Agent is thus managed, while the Router Agent can be in another environment.
Installer screen resolutionWhen the Installer is run in GUI mode, a resolution of at least 800 x 600 is required.
Transfer CFT 3.3.2 Installation Guide 7
1 Prerequisites
GUI mode requirement UNIX only
GUI mode is supported on Windows, UNIX, and Linux. However, to use on UNIX platforms, the installer requires an X-Window environment. To use an X-Window distributed environment on Unix, you must export the DISPLAY environment variable: export DISPLAY=myhost.mydomain:0.0
UNIX specific requirementsUNIX users are required to have Korn Shell (ksh) installed on all UNIX machines.
UNIX user for starting the productsFor Transfer CFT you can use any user to install and start the product except the user root , which is forbidden. Make sure the user has the standard read and write permissions on the installation directory.
Umask informationThe various processes create files during the runtime execution. To ensure that these files are properly used by all the processes, you must make sure that the user has all the rights on the created files. Use the command, umask -S u=rwx.
Depending on your information system architecture and whether or not you need to share files with other products, you can grant rights on these files to users from group or others. For this option use the command, umask -S go=rx.
Red Hat 6 platformAxway Installer supports installation on a Red Hat 6 platform however:
l On a 64-bit Linux operating system, the installer starts with the 64-bit JRE by default. If it cannot find the 64-bit JRE it will look for the 32-bit JRE.
l If you want your installation to start smoothly on a Red Hat 6 operating system you must make sure you have the following packages installed on your system because they may not have been installed by default.
o glibc.i686
o nss-softokn-freebl.i686
HP-UX requirementsFor HP-UX ia64 and HP-UX PA-RISC
Transfer CFT 3.3.2 Installation Guide 8
1 Prerequisites
HP-UX Password Hashing Infrastructure, PHI, enables the use of SHA512-based algorithms for user password hashes (rather than DES). This package is required for Transfer CFT, as it is more secure and provides a new function, crypt2(), for user control.
For more information, refer to HP-UX Password Hashing Infrastructure Release Notes.
Global environment on a Unix machineTo install on a UNIX machine, you need a specific Unix user ID and enough free space to install in the users home directory.
The default installation path is the users home directory, but you can change the path and install all products in a specific file system.
The installation directory must not contain any sub-folders or files that are owned by another user.
Using a temporary directoryThe installer needs a temporary directory when it starts to unzip and prepare the environment it requires for product or update installation.
By default, it will try one of the following directories: /tmp , /var/tmp , /usr/tmp , $HOME , $PWD.
You can force the use of another temporary directory by setting the following environment variable, TEMPORARY_DIR.
If you do this, make sure the temporary directory has:
l Enough disk space
l Read/write access for starting the installer
Using installer on HP-UX 11i The installer is packaged with an embedded JRE 6. For the JRE to run properly on a HP-UX 11i operating system, you need to apply a linker patch to fix the problem loading libjli.sl.
The following patch is required:
l HP-UX 11i v3 (11.31) PA-RISC systems: PHSS_37202
If you do not apply the patch you will get an error message when you start the installer. Check that the AxwayInstaller# directory is deleted in the temp directory.
Transfer CFT 3.3.2 Installation Guide 9
1 Prerequisites
Customize the kernel
About kernel customizationDepending on the operating system, some customization may be mandatory to ensure that Transfer CFT operates correctly, and to maintain the overall system performance levels.
Kernel customization is not mandatory for installation, but is needed to run Transfer CFT.
This section describes the kernel parameters that you need to upgrade to ensure that the Transfer CFT operates correctly, and is comprised of the following topics:
l Why customize the kernel?
System specific customization procedures are described for the following systems:
l HP-UX
l Linux
l Solaris
Note No additional steps are necessary to modify the IBM AIX kernel as the ODM (Object Data Manager) manages this.
For additional information on customization issues, contact your system administrator or the manufacturer's support service.
Customization detailsKernel customization concerns one or more of the following aspects:
l Size of the global shared memory segment: modification recommended but not mandatory
l Message queue depth: modification mandatory
l Memory allocated to TCP: modification mandatory
l Number of files used by a process: modification mandatory
Depending on the operating system, some customization may be mandatory to ensure that Transfer CFT operates correctly, and to maintain the overall system performance levels.
Note:
l The kernel customization requires an in-depth knowledge of UNIX. To make the recommended changes, you must have super-user privileges (root). An incorrect setting could seriously affect the integrity of your system.
l The figures indicated are based on a standard system, which is the default configuration used when the operating system was installed. If you have already changed a specific setting for another application, the current parameter value must be increased by the one recommended for Transfer CFT.
Transfer CFT 3.3.2 Installation Guide 10
1 Prerequisites
Why customize the kernel?This topic explains the advantages of customizing the kernel, and additionally presents the following related subjects:
l Global memory segment
l Message queue depth
l Memory allocated to TCP
l Number of files used by a process
Global shared memory segmentBy default, you can only create a global memory segment for a size defined in terms of the kernel.
Transfer CFT can attempt to create a 32 MB global memory segment. Transfer CFT uses this global memory for data exchanges during the execution of various operational tasks. The 32 MB value represents the average size necessary to support efficient performance without slowing the system, due to memory saturation.
We strongly recommend that you change the kernel configuration, even though Transfer CFT automatically adapts to the maximum size authorized by the system. The reason for this is that if the memory is insufficient, Transfer CFT slows down significantly.
In some cases, when receiving transfers from high-speed systems via TCP, you may notice interlocks preventing Transfer CFT from running correctly. If the capacity of the system cannot support the resulting overload, you must reduce the number of concurrent transfers.
As the system can accommodate this modification, it is recommended that the maximum size of the shared memory segment be systematically increased to at least 32 MB.
Message queue depthBy default, some UNIX systems allow a maximum of 40 unread messages to transit in a message queue.
To guarantee optimum performance levels, Transfer CFT maximizes its use of the message queues. It may be that Transfer CFT requirements exceed the system capacity. This is the case particularly over TCP networks, when the remote monitor + network configuration allows a throughput exceeding the capacities of the local system. This phenomenon becomes even more likely if another application is also making intensive use of the message queues.
Memory allocated to TCPWhen first installed, Open Server allocates a certain amount of memory to allow the IP layer to operate correctly. Open Server adjusts this memory allocation as required, up to a given maximum.
Transfer CFT 3.3.2 Installation Guide 11
1 Prerequisites
When this maximum is reached, following a request by a local application, the request is refused. However, when this saturation is due to the network, Open Server waits for space to be released on the local system so that it can continue processing.
When this saturation phenomenon occurs, the remote Transfer CFT and network permit an overall throughput that is too high for the local system, given the close link between Transfer CFT and the data transiting on the network, so this space cannot be released. The phenomenon is even more likely if another application is also making intensive use of the network memory.
To ensure Transfer CFT operation, you must modify the kernel to increase the size of the memory allocated to TCP.
Number of files used by a processBy default, some UNIX systems allow a process to only open 64 files at the same time.
If you do not modify this limit, you cannot use Transfer CFT to its full potential: 64 concurrent transfers + link channels + listening channels + trace channels > 64 open files.
To achieve 64 concurrent transfers, you must modify some of the kernel properties so that it can open as many files as possible; 1024 is suggested.
HP-UX: Customize the kernelThis topic provides information on customizing the HP-UX kernel, and how to:
l Modify the message queue depth
l Modify the number of files used by a process
Modify the message queue depthBy default, HP-UX only allows a maximum of 256 unread messages to transit in a message queue. To customize this information, increase the value of the msgtql kernel parameter to 8192.
To customize the message queue:
1. Log in as the root and enter the sam command.
2. Select the following sub-menus, respectively:
l Kernel Configuration
l Configurable Parameters
3. Set the pointer to the msgtql parameter.
4. Select the Modify Configurable Parameter option in the Actions menu.
5. Enter the new value of this parameter.
6. Click on OK to confirm the change.
7. Select the Add Exported File System option in the Actions menu.
Transfer CFT 3.3.2 Installation Guide 12
1 Prerequisites
8. Select the Exit option in the File menu.
9. Select the Create a new kernel now option and click on OK to confirm your selection.
Modify the number of files used by a processBy default, HP-UX allows a process to open only 64 files. To customize this information, increase the value of the maxfiles kernel parameter to 1024. To do so:
1. Log in as the root and enter the sam command.
2. Select the following sub-menus:
l Kernel Configuration
l Configurable Parameters
3. Set the pointer to the maxfiles parameter.
4. Select the Modify Configurable Parameter option in the Actions menu.
5. Enter the new value for this parameter.
6. Click on OK to confirm the change.
7. Select the Add Exported File System option in the Actions menu.
8. Select the Exit option in the File menu.
9. Select the Create a new kernel now option and click on OK to confirm your selection.
Linux: Customize the kernelThis section describes suggested kernel customizations to perform prior to an installation to better enable Transfer CFT operations.
Kernel customization parametersThe following table lists IPC tuning parameters to consider customizing and recommended values.
Note To aid in correctly calculating semaphores, remember that each Transfer CFT has two semaphores per instance.
Parameter Recommended
value
Description
msgmax 8192 Maximum size of a message in bytes.
msgmnb 16384 Maximum size in bytes on a single IPC message queue.
Transfer CFT 3.3.2 Installation Guide 13
1 Prerequisites
Parameter Recommended
value
Description
msgmni 48 per Transfer CFT instanceSee NOTE**
Maximum number of IPC message queue resources allowed. You require as many message queues as processes per Transfer CFT instance (when using multiple instances, multiply the number of instances by the number of Transfer CFT processes).
shmall(shmall*PAGE_SIZE)
2097152(8 GB when page_size = 4096)
The total amount of shared memory available on the system is 2097152*4096 bytes (shmall*PAGE_SIZE) which is 8 GB. This number may be affected by the use of a very large number of Transfer CFT instances.
shmmax 33554432 Maximum size in bytes for a shared memory segment.
shmmni 4096 Number of shared memory segment identifiers in the system.For each Transfer CFT instance you need 2 shared memory segments, so when using multiple instances or multi-node, multiply the number of instances by 2.
shmseg 10 Maximum number of shared memory segments per process.
semmsl 250 Maximum number of IPC semaphores per set.
semmns 32000 Number of IPC system-wide semaphores.
semopm 100 Maximum number of semaphore operations that can be performed per semop(2).
semmni 128 Maximum number of IPC system-wide semaphore sets.For each Transfer CFT instance you need 2 semaphore sets, so when using multiple instances or multi-node, multiply the number of instances by 2.
Transfer CFT 3.3.2 Installation Guide 14
1 Prerequisites
Note **This value is based on the number of processes started by the Transfer CFT. This minimum is typically 7, but can be in excess of 40 depending on the values for maxtask, sslmtask, Sentinel if enabled, one task for each exit, etc.
Solaris: Customize the kernelThis topic describes how to customize Solaris for Transfer CFT.
l About resource controls
l Selecting a project
Solaris 10 Transfer CFT makes extensive use of System V IPC services and file access services. As of the Solaris 10 release, the corresponding configuration parameters are no longer kernel parameters, but instead can be defined as resource controls.
About resource controlsWhile most of the corresponding parameter default values are suitable for normal Transfer CFT functioning, three of these parameter values must have at least the following minimum values:
Resource control Transfer CFT minimum value
project.max-shm-memory 33554432
process.max-msg-messages 8192
process.max-file-descriptor 1024
This means that you must modify the corresponding resource controls to meet the requirements of the project associated with the user account that Transfer CFT will run under.
Selecting a projectIf you plan to run Transfer CFT under the "axway" user account, for example, create a project associated with the user "axway" using the following system command: projadd -p 201 -G axway -U axway -c "Axway" axway
This command creates the project "axway" and associates the uid axway and gid axway with this project.
Alternatively, you may choose to not associate a specific project with Transfer CFT. In this case, Transfer CFT will run under a project named "default".
Transfer CFT 3.3.2 Installation Guide 15
1 Prerequisites
For the following command examples, we use "cft_project" as the name of the project chosen for Transfer CFT. This can be either a specific project (named "axway", in the example above) or simply the project "default".
Change the maximum size of global memory segments
The following command sets this value to 32 MB:
projmod -s -K "project.max-shm-memory=(privileed,33554432,deny) cft_
project
Change the maximum number of messages
The following command sets this value to 8192:
projmod -s -K "process.max-msg-messages=(privileged,8192, deny) cft_
project
Change the maximum number of open files per process
The following command assigns a value of 1024 to this parameter:
projmod -s -K "process.max-file-descriptor(privileged,1024, deny) cft_
project
Transfer CFT 3.3.2 Installation Guide 16
1 Prerequisites
Default portsThe following list contains the default Transfer CFT port numbers used for installation. You can check in advance that these ports do not conflict with ports used by other applications on the same machine.
You may need to modify the default port numbers, depending on your configuration.
The Internet Assigned Numbers Authority (IANA) reserves the TCP ports 1761-1768 for Transfer CFT. For more information, refer to: www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.
Component Port
PeSIT 1761
SSL 1762
COMS 1765
Copilot 1766
Copilot for Central Governance 1767
REST API 1768
Central Governance 12553
Central Governance SSL 12554
Secure Relay MAma.comm_port
6801
Secure Relay RA
l ra.comm_port
l ra.admin_port
l 6811
l 6810
Legend:
l PeSIT (PESITANY protocol): PeSIT in plain text
l SSL: PeSIT protocol over SSL/TLS
l COMS: Synchronous transfers
l Copilot: Provides access to Transfer CFT Copilot server from a user Internet browser
l Copilot for Central Governance: Provides secure access for Central Governance (mutual authentication)
l Central Governance: Used to connect to Central Governance
Transfer CFT 3.3.2 Installation Guide 17
1 Prerequisites
CertificatesUsing the default certificates that are supplied with Transfer CFT is strongly discouraged in a production environment. You should use your own certificates to enhance security.
Type Location Certificate Expires
Secure Relay <Transfer_CFT>/home/distrib/xsr
SecureRelayCA.pem November 2021
SecureRelayMasterAgent.p12 November 2021
Central Governance
<Transfer_CFT>/runtime/conf/pki
passportCA.pem November 2019
Shared file system prerequisitesThis section provides general information concerning the prerequisites for shared file systems for the following types of files used with Transfer CFT in a UNIX environment.
l Transfer CFT data files: This refers to all files managed by Transfer CFT other than transferable application files (including database files), which are stored in the Transfer CFT runtime directory.
l Transferable application files: This refers to the files transferred by Transfer CFT.
Standalone installationYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/passive clusterYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/active cluster
Transfer CFT data filesSupported shared file systems for multi-node, multi-host architecture (active/active)
Transfer CFT 3.3.2 Installation Guide 18
1 Prerequisites
The following non-exhaustive table lists shared file systems that have been tested with Transfer CFT.
Operating system
Supported Unsupported
AIX GPFS (recommended), NFSv4 NFSv3, CXFS, VeritasSF
HP-UX NFSv4 NFSv3, CXFS, VeritasSF
Linux-x86 GPFS (recommended), GFS2, NFSv4, AWS EFS
NFSv3, CXFS, ACFS, OCFSv1, OCFSv2, QFS, VeritasSF
OpenVMS RMS
Solaris NFSv4 NFSv3, CXFS, QFS, VeritasSF
Windows-x86 CIFS CXFS, NFS
z/OS Sharing DASD across Sysplex
Transfer CFT transferable application filesYou can use any POSIX compliant shared file system for transferable application files.
Transfer CFT 3.3.2 Installation Guide 19
2 Install
Before you startIf you are installing Transfer CFT as part of a managed file transfer solution, you may want to check the installation order and prerequisites. For more information, please refer to the Central Governance documentation.
During the installation process you are prompted to select if you want to enable Central Governance. Please check that your license includes Central Governance and that you have the required information, such as the shared secret, to activate connectivity.
Before you start the installation, you should:
l Downloaded the installation package from Axway Sphere.
l Uncompressed or unzipped the package.
Installation package contentsThe installation package is a zip archive. Once you unzip it, it contains the product and installer program files.
Installation functionsThe installer is used to install, configure, update and uninstall Transfer CFT. You can run the following installation modes:
l Install
l Configure
l Update
l Uninstall
Installation modesLocate and run the setup file in the root folder of the installation package.
GUI mode:
setup.sh
Transfer CFT 3.3.2 Installation Guide 20
2 Install
Console mode:
setup.sh -m console
The setup32.exe is a 32-bit build executable and will run on a 64-bit platform provided that the compatibility layer has been installed.
Installed directoriesOnce you install Transfer CFT, the following sub-directories are installed:
l Configuration: Includes the configuration file for each installed product
l Documentation: User documentation
l Installer: Files used by the installer
l Java: The deployed JRE used by the installer and Axway products
l SilentFile: Includes the silent file for each installed product
l synInstall: Installer internal files that are used to manage the installed infrastructure
l Tools: Tools used by the installer to manage infrastructure instances. You can use some of these for example, XDBM and SilentFileEditor
l Transfer_CFT: the product folders and files
System language settingIf your system uses a language other than English, you will need to change the system to English for the installation and then reset to your original language as needed.
Example in a Linux environment
If you are uncertain as to the current system language setting, use the command env|grep LANG.
export LANG=en_US.utf8
Start the installation You can use this topic to plan and execute installation of Transfer CFT. If you are using Adobe Reader, you can add comments to document the data you need to enter after launching the installer. Otherwise, you can print the topic, enter data manually and use the notes when installing.
Once you have completed planning, you are ready to install. See the section About the installer, in this Installation Guide, for details on how to start the installer in install mode.
To configure Transfer CFT for installation, perform the following procedure. Pending your license key options and environment, however, you may have only a subset of the following screen selections.
This table displays a basic installation, a standalone Transfer CFT, with no options.
Transfer CFT 3.3.2 Installation Guide 21
2 Install
Screen Description
Welcome Provides links to the Axway website and Sphere, the Axway support site.
License agreement
Select the check-box "I accept..." to continue with the installation.
Installation architecture
Select Single to install Transfer CFT on a single machine. Select Cluster to install Transfer CFT on multiple machines (cluster mode). Use this option if you want to install Transfer CFT for a multi-host/multi-node architecture, or active/passive mode.
Note If you select cluster, additional screens display.
Installation directory
Where product files and documentation will reside.
Axway Transfer CFT: Installation directory
Specify the directory where you want to install Transfer CFT.By default, Transfer CFT is installed in a sub-directory of the Axway installation directory. Use the default directory, or specify a new directory.Directory paths cannot contain spaces.
Note If you are installing multiple Axway products, we recommend that you use different directories for each product as the installer overwrites the installer from any previous installation. This can lead to unexpected behavior when applying a patch or service pack.
Axway Transfer CFT: Runtime directory
Specify the directory where you want to install the Transfer CFT runtime directory.By default, the runtime directory is installed in a sub-directory of the Transfer CFT installation directory. Use the default directory, or specify a new directory. A runtime directory will be created if it does not already exist.Directory paths cannot contain spaces.
Axway Transfer CFT: Auto Import
Specify if you want to import data from an existing Transfer CFT by selecting Yes or No.You can install and import configuration and data from v2.3.2, v2.4, v2.5, v2.6, v2.7, v3.0.1, or v3.1.3.
Note If you select Yes in the Auto Import screen, additional screens display.
Axway Transfer CFT: Identity
Check or modify the supplied information concerning the Transfer CFT instance name, group name, and host address.An asterisk * denotes that these fields are mandatory.
Transfer CFT 3.3.2 Installation Guide 22
2 Install
Screen Description
Axway Transfer CFT: Multi-node Architecture
Select to enable multi-node architecture.Enter the number of nodes. The first node is zero, and you may have up to eight nodes. Enter the host name and address for each node. You must enter at least one host.
Note If you enter a number to enable multi-node, additional screens display.
Axway Transfer CFT: License key
Enter the license key for the Transfer CFT product.If you have a license key issued for a previous version of Transfer CFT, enter your license key in the License Key field and select the Check key option.You can configure up to eight keys. Deselect Check key to continue with the installation without a key. However, you cannot run Transfer CFT until you supply the license key.
Note If you are installing in multi-node you require:
l One (1) valid key per node (see details in the multi-node section)
l Among the keys there must be at least one valid key per host
Axway Transfer CFT: Generate Encryption Key
l Please specify a seed password to generate the encryption key.
The password must be at least 8 characters long, it must contain upper and lower case characters as well as numeric and special characters (*#$!?+-@).
l Enter a location to store the generated key and salt files.
Axway Transfer CFT: Governance Mode
Enable Central Governance connectivity:
l Yes: Install Central Governance connectivity. For details, see the Central Governance topics in the Transfer CFT User's Guide.
l No: Installs Transfer CFT without Central Governance.
Axway Transfer CFT: Configuration
Enter the TCP parameters for the host, PeSIT protocol, catalog, and communication media.
l Synchronous communication: enter the COMS port
l PESITANY: Enter the PeSIT protocol port number
l Select the default database size:
o Catalog: Modify the default catalog file size
o Communication File: Modify the default communication file size
Transfer CFT 3.3.2 Installation Guide 23
2 Install
Screen Description
Axway Transfer CFT: User Interface Server
Enter the Transfer CFT UI Server values:
l Listening Port: Listening port for the graphical user interface. This sets the port on which the Transfer CFT UI server listens for incoming TCP connections.
l SSL Listening Port: Defines the SSL connection for the UI server, when Central Governance is selected.
Note: If you enabled multi-node, you are also prompted for the load balancer details.
Axway Transfer CFT: UI Server startup mode
For Windows installations, specify whether you want to start Axway Transfer CFT manually, or to have Windows start and stop it as a Windows service. Select:
l Normal mode: You must manually start and stop the Transfer CFT server
l Service mode: Windows automatically starts and stops the Transfer CFT server. If you select this option, the next installer screen sets the Service parameters.Note: To start Transfer CFT server using service mode from the Copilot server, it is imperative that Transfer CFT service be set up with a specific user account (not using the default system user). If the user is the system user, the Copilot will not be able to start Transfer CFT in service mode.
Axway Transfer CFT: UI Server startup mode
For Windows installations, specify whether you want to start Transfer CFT UI manually, or to have Windows start and stop it as a Windows service. Select:
l Normal mode: You must manually start and stop it.
l Service mode: Windows automatically starts and stops it. If you select this option, you use the next installer screen to set Service parameters.
Transfer CFT 3.3.2 Installation Guide 24
2 Install
Screen Description
Axway Transfer CFT: UI Server service
If you selected Service mode, enter values for the Windows service parameters:
l Service Name: Enter a Windows service name
l Display Name: Enter a Windows service display nameYou can accept the default Service names or modify them. The installer uses these names to create a Transfer CFT service entry in the Windows registry.
l Start Type: Automatic, Manual, Disabled
l Error Control: Ignore, Normal, Severe, Critical
l Use specific account to start the service: Enables you to use a local account instead of a system account
l Domain: Enter the domain name
l Username: Name of the local account
l Password: Enter the user passwordNote: In multi-node, to start the Transfer CFT server using service mode from the Copilot server, it is imperative that Transfer CFT service be set up with a specific user account and domain (not using the default system user). If the user is the system user, Copilot will not be able to start Transfer CFT in service mode.
Axway Transfer CFT: Shortcuts
This screen enables you to install Start Menu shortcuts.
l Yes: Creates shortcuts
l No: Does not create shortcutsThis screen enables you to install desktop shortcuts.
l Yes: Creates shortcuts
l No: Does not create shortcuts
Axway Transfer CFT: Connectors
This screen allows you to select from the following Axway product connectors:
l Sentinel
l Public Key Infrastructure with PassPort
l Access management with PassPortNote If you select any of the available connectors, additional
screens display.
Axway Transfer CFT: Ready to install
Click Install to complete the installation process, or Previous to review or modify installation options.
Transfer CFT 3.3.2 Installation Guide 25
2 Install
Cluster mode screensScreen Description
Installation architecture
Select either:
o Single - Installs Transfer CFT on a single machine.
o Cluster - Installs Transfer CFT on several machines. Select this option if you want to install Transfer CFT in multihost/multi-node or in active/passive mode.
If you are performing a cluster installation and you enable the multi-node option, this creates an active/active Transfer CFT installation. Otherwise, the installation is active/passive.
Cluster o First node: Install on a first machine before adding additional machines (nodes). You must install on a first node before you can select the option to install on additional nodes.
o Additional nodes: After installing on the first machine, you can select this option to install on an additional machine(s).
Installation directories
Specify the root shared directory (shared disk) where the Axway installer programs will reside, and the root installation directory where the product files and the documentation will reside.Windows users can refer to Cluster installation requirements for information on how to create a mapped drive.Directory paths cannot contain spaces.
Axway Transfer CFT: Installation directory for Transfer CFT
Specify the directory where you want to install Transfer CFT. This directory will store all of the Transfer CFT binaries.By default, Transfer CFT is installed in a sub-directory of the Axway installation directory. Use the default directory, or specify a new directory.Select the directory that will store shared data between Transfer CFT machines. It will contain the Transfer CFT runtime.Directory paths cannot contain spaces.
Axway Transfer CFT: Runtime directory
Specify the directory where you want to install the Transfer CFT runtime directory.By default, the runtime directory is installed in a sub-directory of the Transfer CFT installation directory. Use the default directory, or specify a new directory. A runtime directory will be created if it does not already exist.Directory paths cannot contain spaces.
Transfer CFT 3.3.2 Installation Guide 26
2 Install
Auto import (for migration)If you select Yes in the Auto import screen, the following Installer pages display.
Screen Description
Axway Transfer CFT: Migration
Specify if you want to import data from an existing Transfer CFT by selecting Yes or No.You can migrate from V2.3.2, V2.4, V2.5, V2.6, v2.7, v3.0.1, v3.1.x or v3.2.x.
Axway Transfer CFT: Migration
Specify the path to the profile file.
Axway Transfer CFT: Migration Options
This screen is only displayed during a migration operation. You should see the Version, SP, Installation directory and runtime directory display on the screen.Select the objects that you want to import:For V2.5.x and higher:
l Functional configuration objects (PARM/PART)
l Environment objects (UCONF)
l Catalog: CFTCATA
l Communication medium: CFTCOM
l Local PKI base (as of V2.5.1 - SP2)For V2.4.x:
l Functional configuration objects (PARM/PART)
l Environment objects (Sentinel: trkapi.cfg)
l Environment objects (Copilot: copconf.ini)
l Catalog (CFTCATA)
l Communication medium (CFTCOM)
l Local PKI base (as of V2.4.1 - SP6)For V2.3.2:
l Functional configuration objects (PARM/PART)
l Environment objects (Sentinel : trkapi.cfg)
l Catalog (CFTCATA)
l Communication medium (CFTCOM)You have to migrate the following objects manually:
l Executables
l Exits
l APIs
Transfer CFT 3.3.2 Installation Guide 27
2 Install
For more information on importing configuration and data, see Install and auto import.
Multi-node optionsConsider the following when deciding the installation choices as they relate to the multi-node options:
l Single installation mode: Activating the multi-node option installs Transfer CFT on one machine, where you can have several Transfer CFT instances running on a single machine. In this architecture, Transfer CFT is mono-host and multi-node.
l Cluster installation mode: Activating the multi-node option installs Transfer CFT on several machines, with multiple Transfer CFT instances running on each. In this architecture, Transfer CFT is multihost and multi-node.
l If you perform a cluster installation but do not activate the multi-node option, Transfer installs on more than one machine, but with only one running Transfer CFT instance. In this set up, Transfer CFT is installed in active-passive mode.
Screen Description
Axway Transfer CFT: Multi-node Architecture
Select to enable multi-node architecture.Enter the number of nodes. The first node is zero, where you may have up to eight nodes. Enter the host name and address for each node, up to eight nodes. You must enter at least one host.
l If you are performing a cluster installation and you enable the multi-node option, this creates an active/active Transfer CFT installation. Otherwise, the installation is active/passive.
l If you did not perform a cluster installation, selecting the multi-node option creates a local, multi-node installation.
Transfer CFT 3.3.2 Installation Guide 28
2 Install
Screen Description
Axway Transfer CFT: License key
Enter the license key for the Transfer CFT component.If you have a license key issued for a previous version of Transfer CFT, enter your license key in the Key field and check the Check key option.You can configure up to eight keys. Deselect Check key to continue with the installation without a key. However, you cannot run Transfer CFT until you supply the license key.Transfer CFT 3.3.2 SP2 and higherAs of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use a single key for multiple hosts, either:
l The hostname must not be defined for the key, or
l The hostname defined for the key matches the hostname of one of the hosts that composes the multi-node instance
Additionally, the key must have the cluster option.For example, if you have 2 hosts and 4 nodes, you only need one key that matches one hostname (or no defined hostname).Transfer CFT prior to 3.3.2 SP2 If you are using a Transfer CFT 3.3.2 prior to SP2, multi-node architecture requires:
l One key per node, and if there is more than one host you require at least one valid key per host
l Each key must have the cluster optionFor example, if you have 2 hosts and 4 nodes, you require 4 keys with at least one key per host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to reference to the second host
Back to core installation screens (Governance Mode).
For more general information on using multi-node features refer to the Transfer CFT User's Guide, in the topic About multi-node architecture.
Transfer CFT 3.3.2 Installation Guide 29
2 Install
Platform and shared file system supportTransfer CFT supports the following OS for multi-node architecture: Windows-x86, Linux-x86, AIX-power, HPUX-parisc, HPUX-ia64, Sun-SPARC, Sun-x86, and z/OS.
Governance optionsScreen Description
Axway Transfer CFT: Central Governance connectivity
This screen is only displayed if you enabled Central Governance connectivity. Enter values for the following parameters:
l CG Host Address: Sets the server hostname on which the connector will connect
l CG Port: Sets the port on which the connector will connect
l Specify Custom Certificate: If selected, enter the certificate to authenticate Central Governance.
l Shared Secret
l Confirm Shared Secret
l Configuration Policy
For general information on Central Governance, see the Governance services topic in the Transfer CFT Installation Guide.
Connector optionsScreen Description
Axway Transfer CFT: Connectors
Specify the connectors that you want to configure and activate:
l Sentinel
l PKI with PassPort
l Access Management with PassPort
Transfer CFT 3.3.2 Installation Guide 30
2 Install
Screen Description
Transfer CFT:Sentinel Connector
This screen is only displayed if you enabled Sentinel connectivity. Enter values for the following parameters:
l Sentinel Host Address: Sets the Sentinel server hostname on which the connector will connect to
l Sentinel Port: Sets the Sentinel Server port on which the connector will connect to
Connector parameters
l Log Filter
l Transfer Filter: Select the level of information, warning, error and fatal messages you want to receive: All, Summary, No
l Enable Sentinel Heartbeat: Check to enable
Transfer CFT:PassPort PKI connector
This screen is only displayed if you enabled PassPort PKI connectivity. Enter values for the following parameters:
l PKI Server Host Address: Sets the PassPort server hostname on which the connector will connect.
l PKI Server Port: Sets the PassPort PS port (PS socket server port, or PS secure socket server port) on which the connector will connect.
o Use SSL
o PKI server public certificate
o Copy certificate
o PKI server login
o PKI Server Password
o Confirm PKI Server Password
Transfer CFT 3.3.2 Installation Guide 31
2 Install
Screen Description
Transfer CFT:PassPort Access Management connector
This screen is only displayed if you enabled PassPort AM connectivity. Enter values for the following parameters:
l AM Server Host Address: Sets the PassPort server hostname on which the connector will connect.
l AM Server Port: Sets the PassPort AM server port (API server, or secure API server) on which the connector will connect.
o Use SSL
o AM Server public certificate
o Component instance
o Domain
o Component Login
o Component Password
o Confirm Password
Cluster installationsThis section describes the recommendations when installing a Transfer CFT cluster architecture. Before starting a new Transfer CFT multi-node installation though, check the prerequisites and Release Notes. See also the User Guide section Manage muli-node architecture.
Note Active/passive shared disks must be POSIX compliant.
OverviewA multi-node installation architecture allows installing Transfer CFT binaries on several hosts, physical or virtual server, and Transfer CFT runtime files on shared file system.
The multi-node feature allows for executing multiple Transfer CFTs (called Transfer CFT nodes) on one or several hosts. The set of Transfer CFT nodes is called a Transfer CFT instance.
A combination of both features provides following possibilities:
l A single installation of Transfer CFT with multi-node (HA)
o Install Transfer CFT using the Single installation architecture of the Axway Installer and enable the multi-node architecture.
o Only one execution of the installation procedure is needed.
o Transfer CFT binaries and runtime files must be installed on a shared file system in order to be accessed from several hosts.
o Both binaries and runtime files are shared.
Transfer CFT 3.3.2 Installation Guide 32
2 Install
Note To patch Transfer CFT binaries, the Transfer CFT instance (all of Transfer CFT nodes) must be completely stopped.
Transfer CFT 3.3.2 Installation Guide 33
2 Install
PrerequisitesWhen installing a Transfer CFT cluster, the user performing the installation must:
l Be the same user for all machines.
l Have all rights (create/modify/delete) to the shared disk on all machines when Transfer CFT is installed in multi-host architecture.
Transfer CFT 3.3.2 Installation Guide 34
2 Install
Platform and shared file system supportTransfer CFT supports the following OS for multi-node architecture: Windows-x86, Linux-x86, AIX-power, HPUX-parisc, HPUX-ia64, Sun-SPARC, Sun-x86, and z/OS.
Active/active multi-node (HA) installationA cluster installation of Transfer CFT with multi-node (HA)
l Install Transfer CFT using the Cluster installation architecture of the Installer and enable the multi-node architecture.
l Installation procedure must be executed on each host:
o The first host installation (meaning the first node as defined in the Axway Installer) sets the Shared directory, the <Transfer_CFT Shared> directory and all of the Transfer CFT configurations.
o During each host's installation (meaning additional nodes as defined in the Axway Installer), you are prompted to specify the shared directory, and all parameters from the first installation will be automatically loaded.
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a shared file system.
l Only runtime files are shared.
l At any given time:
o One or several hosts are active.
o All Transfer CFT runtime environments (Transfer CFT nodes) are running.
Note Transfer CFT binaries can be patched on each host one after the other without stopping the Transfer CFT instance (all of the Transfer CFT nodes).
Active/passive cluster installationA cluster installation of Transfer CFT without multi-node (active/passive)
l Install Transfer CFT using the Cluster installation architecture of the Axway Installer and disable the multi-node architecture.
l Installation procedure must be executed on each host:
o The first host installation (meaning the first node as defined in the Axway Installer) sets the Shared directory, the <Transfer_CFT Shared> directory and all of the Transfer CFT configurations.
o During each hosts installation (meaning additional nodes as defined in the Axway Installer), you are prompted to specify the Shared directory, and all parameters from the first installation will be automatically loaded.
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a shared file system (such as NFSv3, NFSv4, GPFS, etc.).
l Only runtime files are shared.
Transfer CFT 3.3.2 Installation Guide 35
2 Install
l At any given time:
o Only one host is active
o Only one Transfer CFT runtime environment is running on the active host
Note Transfer CFT supports all POSIX file systems.
Install the cluster nodesThere are two general steps for installing a product in a cluster.
1. Install first node in cluster.
2. Install additional nodes in cluster.
After installing a product on two or more nodes, you must configure the cluster for high-availability operations. The procedure for cluster configuration varies depending on the type of platform on which the cluster is installed.
Install first node in clusterUse this procedure to install the product on the first node in a cluster:
1. Launch the installer on the machine that supports the first node.
2. On the Installation architecture page, select Cluster and click Next.
3. On the Cluster page, select First node and click Next.
4. On the installation directories page, specify values for the following and click Next.
Note After installing applications in active/passive mode, you must implement the cft start, cft stop, and cft status scripts for the cluster.
Shared Directory
This is the path and name of the directory where you want to create a shared directory for the cluster installation. The shared directory is used to store product data files.
The installer proceeds with the standard sequence of pages for the product.
Installation Directory
The path and name of the local directory where you want to install the first cluster.
Install additional nodes in a clusterUse this procedure to install the product on additional nodes in a cluster:
1. Launch the installer on the machine that hosts the additional node.
2. On the Installation architecture page, select Cluster and click Next.
3. On the Cluster page, select Additional nodes and click Next.
4. On the installation directories page, specify values for the following and click Next.
Shared directory
Transfer CFT 3.3.2 Installation Guide 36
2 Install
Path and name for the shared directory that you entered for the first node. The shared directory is used to store product data files.
The installer installs the product on the second node and configures the shared directory for sharing between the installed nodes.
Silent mode installationSilent mode enables you to perform an installation or configuration in a non-interactive mode. You do not have to enter any parameters in the GUI or console.
To use this mode, you must install the product or run the installer program and perform configuration until just before you click Install. Then in your home installation directory you will have the silent file template you can use to duplicate installations on other machines.
Silent file conceptsThe purpose of using a silent file is to quickly duplicate an installation on multiple machines without running the installer and entering the same parameters over and over again.
The installer's silent mode takes these values from existing or generated silent files. Before you can use this procedure, you must have the necessary silent files available. You can generate these files by installing a product at least once by completing the dialogs up until the point of clicking Install.
CreationA silent file can be created:
l After an installation
or
l After completing the installer dialogs up until the point of clicking Install
The installer's SilentFile directory contains the properties file (Install_Axway_Installer_V4.8.0.properties) and the product property files you might need to install. You must not modify anything in this file except the InstallDir,InstallationLogicalName and list of IncludeFiles. The product property files cannot be used outside of the main installer file.
LocationThe silent file is created in:
<<install directory> >\SilentFile\<InstallationDateTime_Action>\<Install_ProductShortName_V<Version>.properties
Where:
l InstallationDateTime corresponds to Year_Month_Day_Hour_Minute_Second.
l Action corresponds to the action done, for example if you performed an install or configure.
Transfer CFT 3.3.2 Installation Guide 37
2 Install
VariablesA silent file is a collection of parameters in the form of key-value pairs, each on one line. The variable stores the name of the parameter (it is the key) and the value stores the other string.
The structure of a variable inside the silent file is:
Variable = Value
Note The extra spaces around the variable are trimmed.
Some special types of variables can be identified.
Variable.Property = Value
Variable.Default = <LinkToAnotherVariable> | Value
A variable property signifies or provides some additional information about that specific variable (commonly known as metadata; it might be used for validation purposes, for parsing purposes, etc.).
For example, information on the creation date:
CreationDate = 13-02-2010
CreationDate.Format = dd-MM-yyyy
Specify the creation date of the silent file (currently, the date the silent file was last modified by the build tool – effectively the date of the build used by the current kit) and below, the format used to parse this date variable (the format used by the date variable).
If a value is missing, the installer takes the default value instead. If the default value links to another variable, the link is replaced by the value of the linked variable (this is called a feedback link).
Encrypted variables
For security reasons, some variables (passwords) are encrypted in the silent case. This means the Format property contains the used encryption algorithm (default is plain).
l If you want to change the value of an encrypted variable, you must use the silent file editor tool
l You can disable the encryption of the variable by deleting the Format property
Environment variables
If you need to deploy a product installation on several machines, with only a few changes to make on the installation parameters, use the same silent file. In the silent file you can replace the unwanted parameters with environment variables that you defined on your machine before the installation. You can then use these variables instead of the Variable Values.
You can use environment variables when installing or configuring in Silent mode (limited to Silent mode only.)
l UNIX and Linux: ${env_var}
Transfer CFT 3.3.2 Installation Guide 38
2 Install
There are restrictions for certain variables and therefore you cannot use an environment variable for the following parameters:
l Component properties
l Variable properties
l Installer variables (in the file Install_Axway_Installer_VX.Y.Z.properties), except InstallDir,InstallationLogicalName
Example
You can use any text editor or the Silent File Editor to modify variables in the silent file.
An example of changing the installation directory:
InstDir = C:\<install directory>\
InstDir.Type = String
InstDir2 = C:\<install directory>\Composer
InstDir2.default = <InstDir>/Composer
Using silent modeTo run the installer in silent mode, you need the following commands:
UNIX:
l setup.sh –s <the absolute path to the installer Silent File>
The installer's silent file is located in <install directory>/SilentFile/<DirectoryDate>/ after installation and is called Install_Axway_Installer_V<version>.properties.
The Silent File directory contains the installer properties file (Install_Axway_Installer_V<version>.properties) and the product property files you might need to install. You should always call the Axway_Installer silent file from the command line no matter the number of products you want to install. You can add or delete products from the silent installation if necessary as long as they exist in the Silent File. Open the Axway_Installer properties file and scroll to the end. You will see a number of IncludeFiles specifying the number of products included for an installation. You must not modify anything else in this file except the InstallDir,InstallationLogicalName and list of IncludeFiles.
The following related to the installation above is very important:
l You must use the absolute path to the silent file and not the relative one
l The command must point to the installer silent file and not the product silent file
l The product silent files installed in silent mode must be in the same directory as the installer silent file
Configure product in silent modeTo configure an installation in silent mode, you need the following commands:
Transfer CFT 3.3.2 Installation Guide 39
2 Install
UNIX:
l configure.sh –s <the absolute path to the installer Silent File>
Silent File EditorUse the Silent File Editor to modify variables in a silent file. It can be used from the command line or the GUI.
The most common values that you replace when preparing a new installation using a silent file are the InstallDir and CommonDir variables. The value of these fields is used to concatenate other paths in the products silent file properties file.
LocationThe Silent File Editor is in the installation directory in Tools/SilentFileEditor.
Note Copying the Silent File Editor from the installation package is not supported because it uses binary files from the installer.
Modifying a silent file using the command lineTo modify a silent file using the command line, run:
l In UNIX: SilentFileEditor.sh
The parameters for the Silent File Editor are:
l The path to the silent file that you want to modify
l Three arguments in this format:
o The first argument is the name of the variable that you want to modify (for example, DB_ADMIN_PASSWORD). Each variable name given must exist in the silent file
o The second argument is the value that you want to assign to the variable given as the first argument
o The third argument is –c if the value is to be encrypted first and then saved in the silent file, or –u if the value does not need to be encrypted
You can have more than one group of arguments as shown in the examples below.
Example
SilentFileEditor.bat SilentFilePath varName1 value1 –c/-u varName2 value2 –c/-u … varNameN valueN –c/-u
Transfer CFT 3.3.2 Installation Guide 40
2 Install
Modifying a Silent File using the user interface
Starting the GUI
To start the Silent File Editor GUI, run SilentFileEditorGUI.bat or SilentFileEditorGUI.sh at <installation directory>\Tools\SilentFileEditor.
Using the GUI
The GUI displays the list of variables and values in the silent file.
Use File > Open to open the silent file you want to edit.
From the Tools menu you can:
l Encrypt Selected: Encrypts the Values selected with the AES128 algorithm
l Undo Selected: Undoes the changes made on the current selection
l Undo all changes: Undoes all changes made on the current selection
l Replace: Finds a variable and replaces it with the value you select. Inside of the Replace command there are other options:
l Replace all: Replaces all paths in all the variable values
l Find next: Goes to the next value occurrence and if you click Replace it replaces the value
l Encrypt: Encrypts the value in the Replace Value with field
Once you have completed all the modifications, use File > Save to save the silent file, then File > Exit to quit the Silent File Editor UI.
Active/active installation This section describes how to install active/active failover, as described in About Multi-node architecture.
Download and uncompressDownload and unzip the Transfer CFT install package, as described in Before you start on page 20.
Commands See the Multi-node commands and management section for details on using Transfer CFT commands and cluster management.
Transfer CFT 3.3.2 Installation Guide 41
2 Install
TroubleshootingPlease see Troubleshoot multi-node.
Shared file system prerequisitesThis section provides general information concerning the prerequisites for shared file systems for the following types of files used with Transfer CFT in a UNIX environment.
l Transfer CFT data files: This refers to all files managed by Transfer CFT other than transferable application files (including database files), which are stored in the Transfer CFT runtime directory.
l Transferable application files: This refers to the files transferred by Transfer CFT.
Standalone installationYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/passive clusterYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/active cluster
Transfer CFT data filesSupported shared file systems for multi-node, multi-host architecture (active/active)
The following non-exhaustive table lists shared file systems that have been tested with Transfer CFT.
Operating system
Supported Unsupported
AIX GPFS (recommended), NFSv4 NFSv3, CXFS, VeritasSF
HP-UX NFSv4 NFSv3, CXFS, VeritasSF
Linux-x86 GPFS (recommended), GFS2, NFSv4, AWS EFS
NFSv3, CXFS, ACFS, OCFSv1, OCFSv2, QFS, VeritasSF
Transfer CFT 3.3.2 Installation Guide 42
2 Install
Operating system
Supported Unsupported
OpenVMS RMS
Solaris NFSv4 NFSv3, CXFS, QFS, VeritasSF
Windows-x86 CIFS CXFS, NFS
z/OS Sharing DASD across Sysplex
Transfer CFT transferable application filesYou can use any POSIX compliant shared file system for transferable application files.
Using a shared file systemIn a multi-node context, a shared file system allows multiple applications to access the same files at the same time. Two typical shared file system implementations are NAS (network attached storage) and SAN (storage area network). This section describes GPFS, NFSv4, AWS EFS, and CIFS as they pertain to Transfer CFT multi-node installations.
Note In Transfer CFT, you can use any Portable Operating System Interface (POSIX) compliant shared file system for transferable application files.
Using GPFS as a shared file systemGPFS, General Parallel File System, is the shared file system of choice for Transfer CFT. It provides high-speed file access for Transfer CFT when executing in a multi-node architecture.
Use the default setting for GPFS usage
By default the shared file system is set to unknown, the value to use for GPFS. If you are uncertain as to the file system setting for the Transfer CFT internal data files, execute the following command to return to the default setting:CFTUTIL uconfunset id=cft.multi_node.shared.filesystem.type
Using NFSv4 as a shared file systemThe recommendations in this section apply to a Transfer CFT multi-node, multi-host architecture based on an NFSv4 shared file system. To implement a Transfer CFT active/active architecture using NFS, version 4 is mandatory. This is because NFSv4 can detect host failures (unlike NFSv3). With host failure detections possible, Transfer CFT can restart another host's nodes when necessary.
Transfer CFT 3.3.2 Installation Guide 43
2 Install
To implement active/active Transfer CFT you must use NFSv4 for the Transfer CFT runtime directory, which contains internal data such as the catalog, log, communication file, etc. Other versions of NFS are not supported for the runtime directory. For file exchanges, you can use either NFSv4 or v3. NFSv3 is not described in this document.
l Required NFSv4 mount options
l Mount options summary
l Synchronous / asynchronous option impact
l Tuning NFSv4 locking for node failover
l Troubleshoot an NFS lock daemon issue
Define NFS as the shared file system
Execute the following command to enable the Transfer CFT internal data files to reside on a NFSv4 file system.Enter the nfs value in lower case:
CFTUTIL uconfset id=cft.multi_node.shared.filesystem.type, value=nfs
Required NFSv4 mount options
Define the NFS versionIf version 4 is not your NFS subsystem's default, you must specify version 4 when defining the mount options. Depending on your OS, use either the vers or nfsvers option.
Set the hard and nointr optionsMount NFSv4 using the hard and nointr options. The intr mount option should not be available for NFSv4, but if you are in doubt, you should explicitly specify the nointr option.
Define file lockingBecause Transfer CFT uses POSIX file locking services to synchronize shared files, make sure that the NFS clients report these locks to the NFS server. Depending on the NFS client, the corresponding option to tune may be called local_lock, llock, or nolock. Do not enable the local locking option.
Set the cto option NFS implements a weak data consistency called "Close To Open consistency" or cto. This means that when a file is closed on a client, all modified data associated with the file is flushed from the server. If your NFS clients allow this behavior, be certain that the cto option is set.
Transfer CFT 3.3.2 Installation Guide 44
2 Install
Mount options summaryThe following table summarizes the recommended NFSv4 mount options. Note that depending on the OS platform, only one of the three locking options should be available.
Correct option Incorrect option
vers=4 (or nfsvers=4) not specified or value <= 4
hard (default) "soft" specified
nointr (not the default) "intr" specified
llock not specified "llock" specified
lock (default) "nolock" specified
local_lock=none (default) any other value specified
cto (default) "nocto" specified
Synchronous versus asynchronous option
To improve performance, NFS clients and NFS servers can delay file write operations in order to combine small file IOs into larger file IOs. You can enable this behavior on the NFS clients, NFS servers, or on both, using the async option. The sync option disables this behavior.
ClientOn the client side, use the mount command to specify the async/sync option.
AsyncThe NFS client treats the sync mount option differently than some other file systems. If neither sync nor async is specified (or if async is specified), the NFS client delays sending application writes to the server until any of the following events occur:
l Memory limitations force reclaiming of system memory resources.
l Transfer CFT explicitly flushes file data (PeSIT synchronization points, for example).
l Transfer CFT closes a file.
This means that under normal circumstances, data written by Transfer CFT may not immediately appear on the server that hosts the file.
Transfer CFT 3.3.2 Installation Guide 45
2 Install
SyncIf the sync option is specified on a mount point, any system call that writes data to files on that mount point causes that data to be flushed to the server before the system call returns control to Transfer CFT. This provides greater data cache coherence among clients, but at a significant cost to performance.
ServerOn the server side, use the exports command to specify the async/sync option (NFS server export table).
AsyncThe async option allows the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage (the disk drive, for example), even if the client is set to sync. This option usually improves performance, however data may be lost or corrupted in the case of an unclean server restart, such as an NFS server crash.
This possible data corruption is not detectable at the time of occurrence, because the async option instructs the server to lie to the client, telling the client that all data was written to stable storage (regardless of the protocol used).
SyncEnables replies to requests only after the changes have been committed to stable storage.
Note For more information on these options, refer to NFS mount and export options in the UNIX man pages (for example, here).
Synchronous / asynchronous option impact
Client Server Internal data Transferable data
Performance
Sync Sync 1 1 Low
Sync Async 2 (secure the NFS server) 2 (secure the NFS server)
Medium
Async Sync 1 (if cft.server.catalog.sync.enable=Yes)
1 (when using sync points)
Medium - high
Async Async 3 3 High
Legend:
Transfer CFT 3.3.2 Installation Guide 46
2 Install
l 1 = Secure
l 2 = Fairly secure
l 3 = Not secure
l Internal data = Transfer CFT runtime files, such as the catalog
l Transferable data = Files exchanged using Transfer CFT
Tuning NFSv4 locking for node failover
The NFSv4 locking lease period affects the Transfer CFT delay required to detect node failovers. The default value for this parameter is typically 90 seconds. On systems where this parameter is tunable, configuring a shorter value can significantly reduce Transfer CFT node failovers.
Troubleshoot an NFS lock daemon issue with no error message
When transferring files that are located in a Network File System, an NFS locking issue (lockd) may occur if the correct port is not open on the firewall.
Symptom
l Flow transfers hang in the phase T and phasestep C, with a timeout but no error message.
Remedy
l Check that the correct port for the lockd service is open on the firewall (default=4045).
Using AWS EFS as a shared file systemThe recommendations in this section apply to a Transfer CFT multi-node, multi-host architecture based on an Amazon Web Services (AWS) Elastic File System (EFS) shared file system.
When using AWS EFS, you cannot set the server options; only the client is configurable.
This system is based on NFSv4. For more information on NFSv4, please see Using NFSv4 as a shared file system.
This shared file system has features that impact performance, as compared to a traditional NFS:
l Distributed systems replicating data
l Processing does not continue until all data is replicated
Using CIFS as a shared file systemWindows only
CIFS, Common Internet File System, shares files across corporate intranets and the Internet, and is available as a shared file system when running Transfer CFT in a Windows environment.
Transfer CFT 3.3.2 Installation Guide 47
2 Install
Install active/passive - UnixThis section describes how to install an active/passive architecture, as described in About Multi-node architecture.
A cluster installation of Transfer CFT without multi-node is an active/passive installation as described below:
l Install Transfer CFT using the Cluster installation architecture of the Installer and disable the multi-node architecture.
l Installation procedure must be executed on each host:
o The first host installation
o Additional hosts installation
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a shared file system.
l Only runtime files are shared.
l You must configure the cluster after installation but before you can use the cluster. The procedure for cluster configuration varies depending on the platform on which the cluster is installed.
l At any given time:
o Only one host is active
o Only one Transfer CFT runtime environment is running on the active host
Note After installing applications in active/passive mode, you must implement the cft start, cft stop, and cft status scripts for the cluster.
Shared Directory
This is the path and name of the directory where you want to create a shared directory for the cluster installation. The shared directory is used to store product data files.
Installation Directory
The path and name of the local directory where you want to install the first cluster.
PrerequisitesTransfer CFT in multi-host architecture requires:
l A shared file system
l You must configure the system prior to the multi-node installation, and the shared disk should be ready when you start the Copilot server. See Shared file system prerequisites for details.
Transfer CFT 3.3.2 Installation Guide 48
2 Install
InstallStart the installer. In the Cluster options, select:
o Cluster - Installs Transfer CFT on several machines. Select this option if you want to install Transfer CFT in active/passive mode.
However, do not enable the multi-node option, as this creates an active/active Transfer CFT installation. Otherwise, the installation is active/passive.
Install first node in clusterUse this procedure to install the product on the first node in a cluster:
1. Launch the installer on the machine that supports the first node.
2. On the Installation architecture page, select Cluster and click Next.
3. On the Cluster page, select First node and click Next.
4. On the installation directories page, specify values for the following and click Next.
Note After installing applications in active/passive mode, you must implement the cft start, cft stop, and cft status scripts for the cluster.
Shared Directory
This is the path and name of the directory where you want to create a shared directory for the cluster installation. The shared directory is used to store product data files.
The installer proceeds with the standard sequence of pages for the product.
Installation Directory
The path and name of the local directory where you want to install the first cluster.
Install additional nodes in a clusterUse this procedure to install the product on additional nodes in a cluster:
1. Launch the installer on the machine that hosts the additional node.
2. On the Installation architecture page, select Cluster and click Next.
3. On the Cluster page, select Additional nodes and click Next.
4. On the installation directories page, specify values for the following and click Next.
Shared directory
Path and name for the shared directory that you entered for the first node. The shared directory is used to store product data files.
The installer installs the product on the second node and configures the shared directory for sharing between the installed nodes.
Transfer CFT 3.3.2 Installation Guide 49
2 Install
Shared file system prerequisitesThis section provides general information concerning the prerequisites for shared file systems for the following types of files used with Transfer CFT in a UNIX environment.
l Transfer CFT data files: This refers to all files managed by Transfer CFT other than transferable application files (including database files), which are stored in the Transfer CFT runtime directory.
l Transferable application files: This refers to the files transferred by Transfer CFT.
Standalone installationYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/passive clusterYou can use any POSIX compliant shared file system for both Transfer CFT data files and transferable application files.
Active/active cluster
Transfer CFT data filesSupported shared file systems for multi-node, multi-host architecture (active/active)
The following non-exhaustive table lists shared file systems that have been tested with Transfer CFT.
Operating system
Supported Unsupported
AIX GPFS (recommended), NFSv4 NFSv3, CXFS, VeritasSF
HP-UX NFSv4 NFSv3, CXFS, VeritasSF
Linux-x86 GPFS (recommended), GFS2, NFSv4, AWS EFS
NFSv3, CXFS, ACFS, OCFSv1, OCFSv2, QFS, VeritasSF
OpenVMS RMS
Solaris NFSv4 NFSv3, CXFS, QFS, VeritasSF
Windows-x86 CIFS CXFS, NFS
z/OS Sharing DASD across Sysplex
Transfer CFT 3.3.2 Installation Guide 50
2 Install
Transfer CFT transferable application filesYou can use any POSIX compliant shared file system for transferable application files.
Using a shared file systemIn a multi-node context, a shared file system allows multiple applications to access the same files at the same time. Two typical shared file system implementations are NAS (network attached storage) and SAN (storage area network). This section describes GPFS, NFSv4, AWS EFS, and CIFS as they pertain to Transfer CFT multi-node installations.
Note In Transfer CFT, you can use any Portable Operating System Interface (POSIX) compliant shared file system for transferable application files.
Using GPFS as a shared file systemGPFS, General Parallel File System, is the shared file system of choice for Transfer CFT. It provides high-speed file access for Transfer CFT when executing in a multi-node architecture.
Use the default setting for GPFS usage
By default the shared file system is set to unknown, the value to use for GPFS. If you are uncertain as to the file system setting for the Transfer CFT internal data files, execute the following command to return to the default setting:CFTUTIL uconfunset id=cft.multi_node.shared.filesystem.type
Using NFSv4 as a shared file systemThe recommendations in this section apply to a Transfer CFT multi-node, multi-host architecture based on an NFSv4 shared file system. To implement a Transfer CFT active/active architecture using NFS, version 4 is mandatory. This is because NFSv4 can detect host failures (unlike NFSv3). With host failure detections possible, Transfer CFT can restart another host's nodes when necessary.
To implement active/active Transfer CFT you must use NFSv4 for the Transfer CFT runtime directory, which contains internal data such as the catalog, log, communication file, etc. Other versions of NFS are not supported for the runtime directory. For file exchanges, you can use either NFSv4 or v3. NFSv3 is not described in this document.
l Required NFSv4 mount options
l Mount options summary
l Synchronous / asynchronous option impact
l Tuning NFSv4 locking for node failover
l Troubleshoot an NFS lock daemon issue
Transfer CFT 3.3.2 Installation Guide 51
2 Install
Define NFS as the shared file system
Execute the following command to enable the Transfer CFT internal data files to reside on a NFSv4 file system.Enter the nfs value in lower case:
CFTUTIL uconfset id=cft.multi_node.shared.filesystem.type, value=nfs
Required NFSv4 mount options
Define the NFS versionIf version 4 is not your NFS subsystem's default, you must specify version 4 when defining the mount options. Depending on your OS, use either the vers or nfsvers option.
Set the hard and nointr optionsMount NFSv4 using the hard and nointr options. The intr mount option should not be available for NFSv4, but if you are in doubt, you should explicitly specify the nointr option.
Define file lockingBecause Transfer CFT uses POSIX file locking services to synchronize shared files, make sure that the NFS clients report these locks to the NFS server. Depending on the NFS client, the corresponding option to tune may be called local_lock, llock, or nolock. Do not enable the local locking option.
Set the cto option NFS implements a weak data consistency called "Close To Open consistency" or cto. This means that when a file is closed on a client, all modified data associated with the file is flushed from the server. If your NFS clients allow this behavior, be certain that the cto option is set.
Mount options summaryThe following table summarizes the recommended NFSv4 mount options. Note that depending on the OS platform, only one of the three locking options should be available.
Correct option Incorrect option
vers=4 (or nfsvers=4) not specified or value <= 4
Transfer CFT 3.3.2 Installation Guide 52
2 Install
Correct option Incorrect option
hard (default) "soft" specified
nointr (not the default) "intr" specified
llock not specified "llock" specified
lock (default) "nolock" specified
local_lock=none (default) any other value specified
cto (default) "nocto" specified
Synchronous versus asynchronous option
To improve performance, NFS clients and NFS servers can delay file write operations in order to combine small file IOs into larger file IOs. You can enable this behavior on the NFS clients, NFS servers, or on both, using the async option. The sync option disables this behavior.
ClientOn the client side, use the mount command to specify the async/sync option.
AsyncThe NFS client treats the sync mount option differently than some other file systems. If neither sync nor async is specified (or if async is specified), the NFS client delays sending application writes to the server until any of the following events occur:
l Memory limitations force reclaiming of system memory resources.
l Transfer CFT explicitly flushes file data (PeSIT synchronization points, for example).
l Transfer CFT closes a file.
This means that under normal circumstances, data written by Transfer CFT may not immediately appear on the server that hosts the file.
SyncIf the sync option is specified on a mount point, any system call that writes data to files on that mount point causes that data to be flushed to the server before the system call returns control to Transfer CFT. This provides greater data cache coherence among clients, but at a significant cost to performance.
Transfer CFT 3.3.2 Installation Guide 53
2 Install
ServerOn the server side, use the exports command to specify the async/sync option (NFS server export table).
AsyncThe async option allows the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage (the disk drive, for example), even if the client is set to sync. This option usually improves performance, however data may be lost or corrupted in the case of an unclean server restart, such as an NFS server crash.
This possible data corruption is not detectable at the time of occurrence, because the async option instructs the server to lie to the client, telling the client that all data was written to stable storage (regardless of the protocol used).
SyncEnables replies to requests only after the changes have been committed to stable storage.
Note For more information on these options, refer to NFS mount and export options in the UNIX man pages (for example, here).
Synchronous / asynchronous option impact
Client Server Internal data Transferable data
Performance
Sync Sync 1 1 Low
Sync Async 2 (secure the NFS server) 2 (secure the NFS server)
Medium
Async Sync 1 (if cft.server.catalog.sync.enable=Yes)
1 (when using sync points)
Medium - high
Async Async 3 3 High
Legend:
l 1 = Secure
l 2 = Fairly secure
l 3 = Not secure
l Internal data = Transfer CFT runtime files, such as the catalog
l Transferable data = Files exchanged using Transfer CFT
Transfer CFT 3.3.2 Installation Guide 54
2 Install
Tuning NFSv4 locking for node failover
The NFSv4 locking lease period affects the Transfer CFT delay required to detect node failovers. The default value for this parameter is typically 90 seconds. On systems where this parameter is tunable, configuring a shorter value can significantly reduce Transfer CFT node failovers.
Troubleshoot an NFS lock daemon issue with no error message
When transferring files that are located in a Network File System, an NFS locking issue (lockd) may occur if the correct port is not open on the firewall.
Symptom
l Flow transfers hang in the phase T and phasestep C, with a timeout but no error message.
Remedy
l Check that the correct port for the lockd service is open on the firewall (default=4045).
Using AWS EFS as a shared file systemThe recommendations in this section apply to a Transfer CFT multi-node, multi-host architecture based on an Amazon Web Services (AWS) Elastic File System (EFS) shared file system.
When using AWS EFS, you cannot set the server options; only the client is configurable.
This system is based on NFSv4. For more information on NFSv4, please see Using NFSv4 as a shared file system.
This shared file system has features that impact performance, as compared to a traditional NFS:
l Distributed systems replicating data
l Processing does not continue until all data is replicated
Using CIFS as a shared file systemWindows only
CIFS, Common Internet File System, shares files across corporate intranets and the Internet, and is available as a shared file system when running Transfer CFT in a Windows environment.
Installer functions
Installer functionsThis section describe functions you can perform with the installer.
Transfer CFT 3.3.2 Installation Guide 55
2 Install
Display commandThe display command lists information about all installed products. The command is named display.bat on Windows and display.sh on UNIX and Linux. Run it from the root installation directory.
When run without parameters, the command lists all installed products and versions and all applied service packs.
Use the name parameter to display the installation history of a single product. For example:
display -n <product name>
Install productTo start the installer to install a product:
Locate and run the setup file in the root folder of the installation package you downloaded from the Axway support site and uncompressed or unzipped.
GUI mode
setup.sh
Console mode
setup.sh -m console
Configure productThis section describes running the installer in configure mode to change a product's configuration.
The following describes running the installer in configure mode.
GUI mode
configure.sh –m gui
Console mode
configure.sh –m console
Note If you do not want to use either the GUI or console modes to configure your installation, refer to the Silent mode.
About host nameHost name corresponds to the object assigned to a physical server. In the installer, host name is required for the following reasons:
Transfer CFT 3.3.2 Installation Guide 56
2 Install
l In a license key page, to validate that the entered key matches the host name. In this case, enter only the host name (without the domain name) and make sure not to confuse Hostname with Logical Server Name.
l In a page where you configure which network interface the product is going to listen for an incoming connection. In this case, enter one of the following values:
o Host name
o The fully qualified name (host name and domain name)
o IP address of the machine
o Specific string (0.0.0.0 or *) indicating that you want the product to listen on all network interfaces if your machine has more than one
o Logical host name or IP address if you are doing an installation on a machine that is part of a cluster
l In a page where you configure how your product is going to connect to another product. In this case, it is strongly recommended to use either the fully qualified name or the IP address of the remote machine. If the remote machine you are connecting to is a cluster, then use the logical, fully qualified cluster host name or IP address.
Using a temporary directoryThe installer needs a temporary directory when it starts to unzip and prepare the environment it requires for product or update installation. The temporary directory it uses is the first %TMPDIR%, %TMP% or %TEMP% environment variable that is not null. It is very important that the value of the variable does not contain any spaces. If it does, a NullPointerException java error occurs.
You can force the use of another temporary directory by setting the following environment variable, TEMPORARY_DIR.
If you do this make sure the temporary directory has:
l Enough disk space
l Read/write access for starting the installer
Installation modesYou can use the following installer installation modes.
l GUI mode is supported on Windows, UNIX and Linux. However, to use on UNIX platforms, the installer requires an X-Window environment. To use an X-Window distributed environment, you must export the DISPLAY environment variable: export DISPLAY=myhost.mydomain:0.0
l Console mode displays a series of prompts requiring user responses or actions.
l Silent mode enables you to perform an installation or configuration in a non-interactive mode. You do not have to enter any parameters in the GUI or console.
Transfer CFT 3.3.2 Installation Guide 57
2 Install
Installer functionsThe installer command files are for invoking installer functions in GUI or console mode.
Before installing, install is the only available function, invoked with the setup file in the root directory of the installation package.
After installing, the configure, update and uninstall functions are available. The scripts for those functions are in the root installation directory.
Function Mode UNIX/Linux
Install GUI setup.sh
Console setup.sh –m console
Configure GUI configure.sh
Console configure.sh –m console
Update GUI update.sh
Console update.sh –m console
Uninstall GUI uninstall.sh
Console uninstall.sh –m console
The configure function lets you change settings that were applied during installation.
The update function lets you apply or remove service packs and patches.
After installing the following functions are available:
l Install product
l Configure product
l Update product and Remove updates
l Uninstall product
l Transfer installation packages on remote machines
JRE customizationTo avoid compatibility issues for a product based on Java, Axway provides the correct JRE, which is installed during the product installation. However, a lightweight installer does not have a JRE. You start the installer with the JRE already installed on your machine. In other words, the installer runs with an external rather than internal JRE.
The advantages are that it allows you more flexibility and saves you on disk space storage.
The infrastructure dependent artifact of the installer is separated into two artifacts (tools and java).
Transfer CFT 3.3.2 Installation Guide 58
2 Install
All Axway products can use an external JRE. This is specifically useful for C coded products as downloading the JREs is no longer mandatory as part of an installation kit.
Installer-dependent deliverablesThe installer-dependent artifacts are split in two parts (tools and java), now that using a standard JRE is optional.
The names of the two artifacts have not changed from the previous ones except they have a -tools and -java suffix:
l The Axway_Installer_VG.M.m_<platform>-tools artifact contains the necessary tools required by the installer which are platform specific and are still mandatory in the installation kit.
l The Axway_Installer_VG.M.m_<platform>-java artifact contains the standard JREs delivered by the installer which are platform specific and are now optional.
Run the installer using an external JRETo run the installer with an external JRE:
l Set the AXWAY_JAVA_HOME environment variable or JAVA_HOME environment variable.
l The installer starts in the following order of precedence with the JRE specified in the:
l Installation kit in the Java/<platform> folder
l AXWAY_JAVA_HOME
l JAVA_HOME
The environment variables need to point to the root of the JRE installation. The Java instance will run from <ENV_VAR_PATH>/bin/java.
Run a product using an external JREThis section describes running products after installing in various modes.
Normal installationWhen you perform a clean installation with the installer using an external JRE, all installed products are configured to use the external JRE. This also means the installer cannot install products that do not support the external JRE.
When you run the installer with either an internal or external JRE for the purpose of managing an existing installation (adding additional features or products), all the products including the newly installed ones will use the JRE configured for the existing installation and not the JRE configured to run with the installer.
When you run the installer in configure mode, it does not apply any changes on the type of internal JRE used. If the installation is configured to use an external JRE, all products are reconfigured to use the new paths specified in the environment variables.
Transfer CFT 3.3.2 Installation Guide 59
2 Install
Caution To set the JRE, the installer uses the path specified in the environment variable at install time, not the environment variable itself. This means that any manual changes you make to the environment variables will not be taken into account. If you want to change the external JRE used by an installation you need to first change the value of the environment variable and then run installer in Configure mode on that installation.
Note that some products do not currently support reconfiguring the Java path. It means that for these products, the Java path cannot be modified using the installer and, if necessary, will have to be done manually.
Caution Do not modify or delete the paths specified in the environment variables used to set the external JRE after installation. If you make any changes to these paths, it will directly affect the functioning of all the installations configured to use them. You should handle any modifications to these environment variables and Java paths with extreme caution.
Silent installationThe parameters from silent files used for specifying the JRE to use will always be overwritten depending on the context of the installation:
For example if you have silent files made from a package which contained Java and a silent installation that is generated with a package without the embedded Java:
l The installer re-computes the Java paths required by the products, and transparently ignores the corresponding settings in the silent file (if any)
l The reverse case is handled in the same manner
Transfer CFT 3.3.2 Installation Guide 60
3 Post installation
Verify your installation You can check the installation log in the <installation directory>/install.log file. See the installation troubleshooting section of the User Guide if you encounter problems with starting Transfer CFT or registering with Central Governance.
Installed directories(missing or bad snippet)
Register with Central GovernanceBegin your registration with Central Governance by starting the Copilot server, which launches the registration process.
Start CopilotTo set the environment variables from the runtime directory prompt enter:
../profile
To start the Copilot server, run the command:
copstart
Verify the Transfer CFT registration with Central Governance
Log in to Central GovernanceIf you have not already done so, log on Central Governance.
Transfer CFT 3.3.2 Installation Guide 61
3 Post installation
In Central Governance from the Product page, check the Product List for your installed Transfer CFT.
See the Troubleshooting installation section in the Transfer CFT User Guide for tips in case of an error.
Start Transfer CFT serverTo start Transfer CFT from the Central Governance interface, use the following procedure.
1. Click Products on the top toolbar to open the page.
2. Select the product (Transfer CFT) to start.
3. Click Start. When started successfully, the Status column displays Started.
View log using Central Governance1. Click the name of the Transfer CFT system on the Product List page to open its details page.
2. Click Logs on the right side of the page.
The log page is displayed where you can:
l Click Refresh anytime to update the log entries.
l Sort the entries by newest or oldest.
l Filter the entries, saving filters for future use.
Note For details on starting, stopping and viewing the Transfer CFT refer to the Central Governance User Guide.
62 Installation Guide Transfer CFT 3.3.2
4 Update, upgrade, or migrate
Start here: Upgrade, update, and migration This chapter is designed to assist administrators or users who are tasked with updating Transfer CFT, or upgrading or migrating from an existing Transfer CFT version to Transfer CFT 3.3.2.
Updates versus upgrade or migrate
About updatesAn update brings Transfer CFT up-to-date with a patch or service pack offering fixes and minor enhancements. For example, you can update a Transfer CFT 3.1.3 SP3 to Transfer CFT 3.1.3 SP8. See Updating Transfer CFT.
About upgradesAn upgrade is the process of updating to a newer, enhanced version of the software. For example, you can update a Transfer CFT 3.1.3 to Transfer CFT 3.2.4. See Upgrading Transfer CFT.
Axway provides Upgrade Packs for products to simplify the process of updating from a previous version. When upgrading, you run the Axway Installer to apply the Upgrade Pack using a procedure that is similar to updating an Axway product. For more information, go to Upgrading Transfer CFT or Upgrading Transfer CFT in multi-node architecture.
This mode has the following advantages (as compared to a migration):
l Allows you to update in the same location
l You can perform this automatically using the Installer, and you can revert to previous state if needed
l Scripts and APIs remain intact and only require a recompilation for the APIs
This mode has the following restriction:
l You must uninstall the upgrade pack if you need to rollback.
l You cannot upgrade on versions older than version 2.6.x.
Transfer CFT 3.3.2 Installation Guide 63
4 Update, upgrade, or migrate
About migrationsA migration means that an initial Transfer CFT is installed in a directory that is not removed or overwritten by the procedure. You can use the OS-appropriate installation kit to install the Transfer CFT 3.3.2 in a new directory, and select the installation option to migrate the existing configuration to this new version. You are only required to provide the path of the Transfer CFT (n-1) version to retrieve this old configuration.
The Transfer CFT versions that are available to migrate include 2.3.2, 2.4, 2.5, 2.6, 2.7, 3.0.1, 3.1.2x, and 3.2.x.
Note If you are migrating from a previous version of Transfer CFT, be sure to check the Release Notes for new features as well as deprecated features and supported platforms per release.
About install and automatic importYou can use an automatic installation procedure to migrate from your current version of Transfer CFT to Transfer CFT 3.3.2. This auto-migration procedure occurs when you perform the Transfer CFT 3.3.2 installation.
This mode has the following advantages:
l The new installation occurs in a new location, and existing configuration elements and data can be automatically imported
l You can install and auto import from versions older than version 2.6.x.
l You can choose to use either of the versions, if needed, in case of an issue with one of the installations
Note Configuration and data, such as the catalog, are in two separate locations and data are not shared.
This mode has the following restriction:
l You must copy scripts and APIs from the previous version to the new installation.
About standard migrationsA standard migration procedure, also used for migrating your existing Transfer CFT to Transfer CFT 3.3.2, is available.
The general procedure for migrating from a previous version of Transfer CFT to Transfer CFT 3.3.2 is as follows:
1. Export existing information from the previous version. Details vary depending on the existing Transfer CFT version.
2. Import the exported information into Transfer CFT 3.3.2.
This mode has the following advantages:
l Because this migration is not automated, you can customize as needed.
l You can perform a standard migration to move from versions older than version 2.6.x.
Transfer CFT 3.3.2 Installation Guide 64
4 Update, upgrade, or migrate
Update or upgrade using Central GovernanceCentral Governance simplifies the management of Transfer CFT and provides identity and access management, certificate security services, monitoring, alerting, and web dashboard services. If you are using Transfer CFT 3.3.2 with Central Governance, you can use the information in Activate Central Unified Flow Management connectivity to configure and register with Central Governance.
Central governance allows you to update (to the latest Transfer CFT Service Pack or patch) or upgrade Transfer CFT (as of Transfer CFT 3.2.4 with the latest SP to the new Transfer CFT version). However, you cannot perform a Transfer CFT migration using Central Governance.
Note You cannot perform an upgrade on the following platforms: z/OS or IBM i.
Important information Important information before performing an upgrade or install auto-import procedure:
l You must update your Transfer CFT to the most recent service pack version.
l Upgrade the Axway Installer to 4.10, if you are not at this version or higher, prior to upgrading your Transfer CFT 3.3.2.
l If needed, you can uninstall an Upgrade Pack. Doing so rolls back to the previous version before the upgrade, but all transfers and configuration modifications that were performed since the upgrade are lost.
l Backup Transfer CFT before beginning an upgrade or migration procedure.
l Before beginning the upgrade or migration procedure stop the existing version of Transfer CFT and the GUI server.
More informationIf you encounter issues when migrating Transfer CFT, contact Axway Support at https://support.axway.com.
Determine the installer and product versionsYou should determine the product and Installer version and service pack level prior to upgrading or updating. You can use the following procedure on any version of the Axway Installer. For more information on the installer, see Installer functions on page 55 and JRE customization on page 58.
Start the Axway installer using the version appropriate command
l Versions lower than 4.5: setupUNIX.sh update
l Versions higher than 4.5: update.sh
Follow the screen instructions to display information, and check the:
Transfer CFT 3.3.2 Installation Guide 65
4 Update, upgrade, or migrate
l Axway Installer version and the most recently installed SP level
l Transfer CFT version and the most recently installed SP level
Alternatively, you can use the display command to list information about all installed products.
l Run the command from the root installation directory.
l When you run this command without parameters, the command lists all installed products and versions, and all applied service packs.
./display.sh
Use the name parameter, - n, to display the installation history of a single product.
Transfer CFT 3.3.2 Installation Guide 66
Update Transfer CFTThis section describes how to update Transfer CFT with a patch or service pack. You can manually perform the operation, or use Central Governance. This section describes how to install or uninstall the update, using silent or console mode.
Download the update fileDownload product updates from the Axway support website to the machine you where you want to perform the update. Please note that the update file is a zip file. Do not unzip this file.
Tip To avoid possible issues if you decide to uninstall a service pack, it is recommended that you install Transfer CFT 3.2.4 SP1 before installing SP2 or higher.
Check product detailsUse the display command to check the version and product details prior to updating, as displayed in red below:
./display.sh -n Transfer_CFT
Transfer_CFT V3.2.4 SP1
Composite: Transfer_CFT_3.2.4_SP2
Note Prior to beginning the update, check the product details as described in Determine the installer and product versions.
Impacted directories when updating a productWhen you install a service pack, the contents of the home directory are updated, but the runtime directory remains untouched. This is so that your customizations, such as APIs, are not overwritten.
Use Central Governance for updatesYou can easily perform Transfer CFT updates and apply Service Packs using Central Governance as of Transfer CFT 3.1.3. Please see the Central Governance documentation for details. Because Central Governance can manage all update operations in a centralized fashion (without intervention on the Transfer CFT side), there is no need to stop the product components on the Transfer CFT machine.
Note that from the Central Governance interface you cannot:
l Remove service packs or patches.
l Update Transfer CFTs installed in multi-node/multi-hosts from Central Governance.
Transfer CFT 3.3.2 Installation Guide 67
Install a standard update Stop Transfer CFT prior to installing a service pack or patch.
Update in silent modeUse the following command to update Transfer CFT in silent mode:
l update.sh -i <zip_file>
Example
./update.sh -i Transfer_CFT_3.2.4-SP1_linux-x86-64.zip
Update in console modeUse the following command to update Transfer CFT in console mode:
update.sh -m console
Uninstall an updateThis section describes uninstalling a patch or service pack. You can uninstall updates in GUI or console mode.
Uninstall updates in silent modeUse this command to retrieve the name to uninstall:
./update.sh -u Transfer_CFT_3.2.4_SP2
Use the following command to uninstall a patch or SP in silent mode:
update.sh -u <update - name>
Example
update.sh -u Transfer_CFT_3.2.4-SP1_linux-x86-64.zip
Transfer CFT 3.3.2 Installation Guide 68
Uninstall updates in console mode 1. From the installation root directory, launch the installer in update mode: update.sh –m
console
2. In the Welcome section, press Enter to continue.
3. In the License agreement section, accept the terms of the license agreement.
4. In the Updates Management section, select option [2] Manage patches and/or service pack. A list of products to update displays.
1. Select the update you want to uninstall.
2. When you move to the next section, Updates Management is displayed again, where you can perform another update action if you need to. If you do not have anymore updates to do, move to the next section.
3. Start the update execution.
4. Review the summary and exit.
Install patches and service packs in a multi-node, multiple host environmentThis section describes the procedure to apply a patch or service pack on a multi-node architecture based on N hosts. You update a Transfer CFT multi-node architecture with multi-hosts using the same procedure as for a patch or service pack, one host at a time.
Note Transfer CFT clusters can still run while performing an update.
1. Connect to the first host.
2. Stop all nodes running on this host by running the command: copstop
Copilot services are stopped, and local nodes are automatically re-started on the other hosts.
3. Check that the nodes are re-started by using the command: CFTUTIL listnode
4. Install the patch or the service pack as usual using the Axway Installer.
5. Start Copilot services.
6. Connect to the next host and repeat the procedure starting at of Step 2 (above).
Transfer CFT 3.3.2 Installation Guide 69
Upgrade Transfer CFT This section explains how to upgrade an existing Transfer CFT from versions 2.6 through 3.2.4 to Transfer CFT 3.3.2. It begins by detailing the prerequisites for a standalone (non multi-node) upgrade. For details on upgrading a multi-node installation, see Upgrade a Transfer CFT multi-node installation on page 82.
About upgradesAll passwords stored in the UCONF dictionary, or in the the Transfer CFT databases (for example, CFTPART, CFTPARM) are cyphered using the key generated at installation. If you are performing an upgrade, all passwords are cyphered using a hard-coded key. We recommend that you generate an encryption key.
Transfer CFT 3.1.3 introduced the CUP, Composite Upgrade Package, feature. This functionality enables you to upgrade both the installer and the product simultaneously.
Note See also silent mode for details on using the silent installation method.
Before you startBefore beginning the upgrade procedure, you should:
l You require the product and Installer version number and SP level in order to choose the appropriate procedure. See the section Determine the installer and product versions on page 65Upgrade Transfer CFT on page 70
l Download the Transfer CFT Upgrade Pack, available at support.axway.com.
l Stop the Transfer CFT server and the Transfer CFT UI server, by entering:
o cft stop
o copstop -f
Use Central Governance to upgrade Transfer CFTYou can perform Transfer CFT upgrades using Central Governance. However, from the Central Governance interface you cannot remove service packs or patches, and can only upgrade Transfer CFT as of Transfer CFT 3.1.3 with last service pack (to the latest version). You cannot perform a Transfer CFT migration via Central Governance.
Please refer to the Central Governance documentation for details.
Transfer CFT 3.3.2 Installation Guide 70
Upgrade Transfer CFT 2.6.4 to 3.3.2Preconditions: Minimum versions for this procedure
This upgrade requires that your current installation is at least at the version levels listed below. Read the Before you start prior to beginning this procedure.
l Transfer CFT version: 2.6.4_SP7
l Axway Installer version: 4.3.1_SP2
l Embedded JRE version: 1.5.0_15
Note Update the product key between versions (after completing the upgrade).
Step 1: Upgrade to Axway Installer 4.4.0 SP8 or the latest SP
Run the Axway Installer in update mode.
1. Start the Axway Synchrony Installer in update mode, shown here in the default installation directory:
Unix/Linux: ***Axway/Synchrony/setupUNIX.sh update
2. Apply the Synchrony_Installer_4.4.0_UP7-from-4.3.1_win-x86-64_BN16272.jar.
3. Start the Axway Synchrony Installer in update mode.
Unix/Linux: ***Axway/Synchrony/setupUNIX.sh update
4. Apply the Synchrony_Installer_4.4.0_SP8_allOS_BN25804.jar.
Step 2: Upgrade to JRE 160
Use the Axway JREUpdateTool to upgrade to JRE 1.6. This Axway tool is available on the Axway Support site.
1. Unzip the JREUpdateTool_4.4.0_Utility_*****_BN1205240348.zip.
Where ***** represents the platform
Example: JREUpdateTool_4.4.0_Utility_win-x86-64_BN1205240348.zip
2. Upgrade to Java 1.6 using the appropriate command:
Unix/Linux: <JRETOOLS_DIRECTORY>/updatejre.sh /home/user/Axway/Synchrony/
Step 3: Upgrade to Axway Installer 4.5.0 SP4 or the latest SP
Run the Axway Installer in update mode.
1. Start the Axway Synchrony Installer in updated mode:
setupUNIX.sh update
2. Apply the Synchrony_Installer_4.5.0_UP1-from-4.4.0-4.4.1_allOS_BN1204251050.jar.
3. Start the Axway Installer.
Transfer CFT 3.3.2 Installation Guide 71
Note The program commands change in this step!
update.sh
4. Apply the Axway_Installer_4.5.0_SP4_allOS_BN22715.jar.
Step 4: Upgrade to JRE 160 update 37 using the JREUpdateTool
Use the Axway JREUpdateTool to update the JRE.
1. Unzip the JREUpdateTool_4.5.0_Utility_*****_BN1211090726.zip
Where ***** represents the platform
Example: JREUpdateTool_4.5.0_Utility_win-x86-64_BN1211090726.zip
2. Upgrade to Java 1.6 using the appropriate command:
<JRETOOLS_DIRECTORY>/updatejre.sh /home/user/Axway/Synchrony/
Step 5: Upgrade to Axway Installer 4.8.0
Run the Axway Installer in update mode.
1. Start the Axway Installer.
update.sh
2. Apply the Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar.
Where ***** represents the platform
Example: Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_BN2.jar
Step 6: Upgrade to Transfer CFT 3.1.3
Run the Axway Installer in update mode.
1. Start the Axway Installer.
update.sh
2. Apply the Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_BN8294000.jar
Where ***** represents the platform
Example: Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_win-x86-64_BN8294000.jar
Step 7: Upgrade to the latest Transfer CFT 3.1.3 Service Pack
Use the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.1.3_SP*****.zip
Where ***** represents the SP level and the platform
Transfer CFT 3.3.2 Installation Guide 72
For example, Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Step 8: Upgrade to the Transfer CFT 3.3.2 Upgrade Pack
Use the Axway Installer in update mode.
1. Start the Axway Installer using one of the two installation modes:
Silent mode: update.sh -i <zip_file>
Interactive mode: update.sh
2. Apply the Transfer_CFT_3.x.y_UP****-from-3.1.3_*****_BN*****.zip.
Where ***** represents the SP level and the platform
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Step 9: Update Transfer CFT 3.3.2 to the latest Service Pack
Transfer CFT 3.3.2 Installation Guide 73
Upgrade Transfer CFT 2.7.1 to 3.3.2Preconditions: Minimum versions for this procedure
This procedure requires that your current installation be at least at the levels listed below.
l Transfer CFT version 2.7.1_SP10
l Axway Installer version 4.4.0_SP8 or 4.4.1_SP3
l Embedded JRE version: 160
Note Remember to update the product key between versions (after completing the upgrade).
Step 1: Upgrade to JRE 160
Use the Axway JREUpdateTool to perform the JRE update.
1. Unzip the JREUpdateTool_4.4.0_Utility_*****_BN1205240348.zip
Where ***** represents the platform
For example, JREUpdateTool_4.4.0_Utility_win-x86-64_BN1205240348.zip
2. Use the following command to upgrade to Java 1.6:
<JRETOOLS_DIRECTORY>chmod 755 *.sh/updatejre.sh /home/user/Axway/Synchrony
Step 2: Upgrade to the Axway Installer 4.5.0_SP4 or the latest SP
Run the Axway installer in update mode.
1. Start the Axway Synchrony Installer, shown here in the default installation directory:
***Axway/Synchrony/setupUNIX.sh update
2. Apply the Synchrony_Installer_4.5.0_UP1-from-4.4.0-4.4.1_allOS_BN1204251050.jar.
3. Start the Axway Synchrony Installer.
Note The program commands change in this step!
Unix/Linux: update.sh
4. Apply the Axway_Installer_4.5.0_SP4_allOS_BN22715.jar.
Step 3: Upgrade to JRE 160 update 37
Use the Axway JREUpdateTool to update the JRE level.
1. Unzip the JREUpdateTool_4.5.0_Utility_*****_BN1211090726.zip
Where ***** represents the platform
For example, JREUpdateTool_4.5.0_Utility_win-x86-64_BN1211090726.zip
2. Upgrade to Java 1.6 using the appropriate command:
<JRETOOLS_DIRECTORY>/updatejre.sh /home/user/Axway/Synchrony/
Step 4: Upgrade to Axway Installer 4.8.0
Transfer CFT 3.3.2 Installation Guide 74
Run the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Axway_Installer_4.8.0_UP**-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar
Where ** is the UP version and ***** represents the platform
For example, Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_BN2.jar
Step 5: Upgrade to Transfer CFT 3.1.3
Run the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.1.3_UP**-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_BN8294000.jar
Where ** is the UP version and ***** represents the platform.
For example, Transfer_CFT_3.1.3_UP2-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_win-x86-64_BN8294000.jar
Step 6: Upgrade to the latest Transfer CFT 3.1.3 Service Pack
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.1.3_SP*****.zip
Where ***** represents the SP level and the platform
Example: Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are now working with a zip file (it was a jar file in previous Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Step 7: Upgrade to Transfer CFT 3.3.2 Upgrade Pack
Use the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.x.y_UP****-from-3.1.3_*****_BN*****.zip.
Where ***** represents the SP level and the platform
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip
Transfer CFT 3.3.2 Installation Guide 75
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Step 8: Update Transfer CFT 3.3.2 to the latest Service Pack
Transfer CFT 3.3.2 Installation Guide 76
Upgrade Transfer CFT 3.0.1 to 3.3.2Preconditions: Minimum versions for this procedure
This procedure requires that your current installation is at least at the levels listed below.
l Transfer CFT 3.0.1_SP9
l Installer 4.5.0_SP4
l Embedded JRE version: JRE 160
Note Remember to update the product key between versions.
Step 1: Upgrade to Axway Installer 4.8.0
Use the Axway Installer in update mode:
1. Start the Axway Installer:
update.sh
2. Apply Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar
Where ***** represents the platform
For example, Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_BN2.jar
Step 2: Upgrade to Transfer CFT 3.1.3
Run the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.1.3_UP**-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_BN8294000.jar
Where ** is the UP version and ***** represents the platform.
Example: Transfer_CFT_3.1.3_UP2-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_win-x86-64_BN8294000.jar
Step 3: Upgrade to the latest Transfer CFT 3.1.3 Service Pack
Run the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.1.3_SP*****.zip
Where ***** represents the SP level and the platform
Example: Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Transfer CFT 3.3.2 Installation Guide 77
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
Step 4: Upgrade to Transfer CFT 3.3.2 Upgrade Pack
Use the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.y.z_UP****-from-3.1.3_*****_BN*****.zip.
Where ***** represents the SP level and the platform
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Step 5: Update Transfer CFT 3.3.2 to the latest Service Pack
Transfer CFT 3.3.2 Installation Guide 78
Upgrade Transfer CFT 3.1.x to 3.3.2Preconditions: Minimum versions for this procedure
The current installation must be at least at the levels listed below.
l Transfer CFT version is 3.1.3
Note Remember to update the product key between versions.
Step 1: Upgrade to the latest Transfer CFT 3.1.3 Service Pack
Run the Axway Installer in update mode.
1. Launch the Axway Installer
update.sh
2. Apply the Transfer_CFT_3.1.3_SP*****.zip
Where ***** represents the SP level and the platform
Example: Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are working with a zip file (not a jar as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
Step 2: Upgrade to Transfer CFT 3.3.2 Upgrade Pack
Use the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
4. Apply the Transfer_CFT_3.y.z_UP****-from-3.1.3_*****_BN*****.zip.
Where ***** represents the SP level and the platform
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip
Step 3: Update Transfer CFT 3.3.2 to the latest Service Pack
Transfer CFT 3.3.2 Installation Guide 79
Upgrade Transfer CFT 3.2.x to 3.3.2Upgrade to Transfer CFT 3.3.2
Use the Axway Installer in update mode.
1. Start the Axway Installer:
update.sh
2. Apply the Transfer_CFT_3.y.z_UP****-from-3.1.3_*****_BN*****.zip.
Where ***** represents the SP level and the platform
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3-3.2.2_aix-power-32_BN10690000.zip
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
4. Update Transfer CFT 3.3.2 to the latest Service Pack.
Transfer CFT 3.3.2 Installation Guide 80
Post upgradeAfter completing the upgrade procedure, your Transfer CFT 3.3.2, exec scripts are operational. However, you must rebuild your programs that use C and COBOL APIs and exits.
After performing an upgrade, all passwords are cyphered using a hard-coded key. We recommend that you generate an encryption key as described in Generate an encryption.
Check the new versionTo check the Transfer CFT version, as well as the license key and system information, enter the command:
CFTUTIL ABOUT
Transfer CFT 3.3.2 Installation Guide 81
Upgrade a Transfer CFT multi-node installationThis section describes how to upgrade a multi-node, multihost Transfer CFT from version 3.0.1, 3.1.2, 3.1.3 or 3.2.x to Transfer CFT 3.3.2.
Before you startBefore beginning the upgrade procedure:
l You require the product and Installer version number and SP level in order to choose the appropriate procedure. See the section Determine the installer and product versions on page 65Upgrade Transfer CFT on page 70
l Download the Transfer CFT Upgrade Pack, available at support.axway.com.
l Stop the Transfer CFT server and the Transfer CFT UI server, by entering:
o cft stop
o copstop -f
Note Transfer CFT clusters must be fully stopped while performing an upgrade.
Transfer CFT 3.3.2 Installation Guide 82
Upgrade Transfer CFT 3.0.1 multi-node to 3.3.2For details on shared disks, node commands, and other multi-node considerations, refer to the Transfer CFT 3.3.2 User Guide > Manage multi-node architecture.
Upgrade all hosts 1. Connect to each machine. Launch the Transfer CFT profile from the Transfer CFT runtime
directory on the shared disk. For example:
cd /<shared_disk>/<CFTdir>/Transfer_CFT/runtime
. ./profile
2. On each host, stop Copilot. This command stops Copilot as well all Transfer CFT nodes running on that machine.
copstop -f
3. Check the status of each Transfer CFT node:
CFTUTIL listnode
4. If Copilot and all nodes are stopped, begin the upgrade procedure as described in Upgrade Transfer CFT 3.0.1 to 3.3.2.
Upgrade the additional hostsRepeat the above upgrade procedure on each additional host.
Restart the upgraded Transfer CFT multihost multi-node environment 1. Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk of
each machine.
cd /<shared_disk>/<CFTdir>/Transfer_CFT/runtime
. ./profile
2. Check the new version using the following command:
CFTUTIL ABOUT
3. Start Copilot (start each of the Copilots in the multi-node environment).
Transfer CFT 3.3.2 Installation Guide 83
copstart
4. After restarting the Copilots, restart the Transfer CFT server:
cft restart
5. Check the upgraded Transfer CFT multi-node multihost system.
CFTUTIL listnode
l All of the Copilots should be started
l All of the Transfer CFT nodes must be started
Your Transfer CFT 3.3.2 exec scripts are now operational. However, you must rebuild your APIs and Exits. Once Transfer CFT has been upgraded on a host you can start that instance, there is no need to wait until Transfer CFT is upgraded on every host.
Transfer CFT 3.3.2 Installation Guide 84
Upgrade Transfer CFT 3.1.3 or 3.2.4 multi-node to 3.3.2For details on shared disks, node commands, and other multi-node considerations, refer to the Transfer CFT 3.3.2 User Guide > Manage multi-node architecture.
Upgrade all hosts 1. Connect to each machine. Launch the Transfer CFT profile from the Transfer CFT runtime
directory on the shared disk. For example:
cd /<shared_disk>/<CFTdir>/Transfer_CFT/runtime
. ./profile
2. On each host, stop Copilot. This command stops Copilot as well all Transfer CFT nodes running on that machine.
copstop -f
l Check the status of each Transfer CFT node:
CFTUTIL listnode
l If Copilot and all nodes are stopped, begin the upgrade procedure as described in Upgrade Transfer CFT 3.1.x to 3.3.2 or Upgrade Transfer CFT 3.2.x to 3.3.2 depending on your version.
Upgrade the additional hostsRepeat the above upgrade procedure on each additional host.
Restart the upgraded Transfer CFT multihost multi-node environment 1. Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk.
cd /<shared_disk>/<CFTdir>/Transfer_CFT/runtime
. ./profile
2. Check the new version using the following command:
CFTUTIL ABOUT
3. Start Copilot (start each of the Copilots in the multi-node environment).
Transfer CFT 3.3.2 Installation Guide 85
copstart
4. After restarting the Copilots, restart the Transfer CFT server:
cft restart
5. Check the upgraded Transfer CFT multi-node multihost system.
CFTUTIL listnode
l All of the Copilots should be started
l All of the Transfer CFT nodes must be started
Your Transfer CFT 3.3.2 exec scripts are now operational. However, you must rebuild your APIs and Exits. Once Transfer CFT has been upgraded on a host you can start that instance, there is no need to wait until Transfer CFT is upgraded on every host.
Transfer CFT 3.3.2 Installation Guide 86
Managing multi-nodeFor details on shared disks, node commands, and other multi-node considerations, refer to the Transfer CFT 3.3.2 User Guide > Manage multi-node architecture.
Transfer CFT 3.3.2 Installation Guide 87
Post upgradeAfter completing the upgrade procedure, your Transfer CFT 3.3.2, exec scripts are operational. However, you must rebuild your programs that use APIs and exits.
After performing an upgrade, all passwords are cyphered using a hard-coded key. We recommend that you generate an encryption key as described in Generate an encryption.
Check the new versionTo check the Transfer CFT version, as well as the license key and system information, enter the command:
CFTUTIL ABOUT
Uninstall an upgrade packThe procedure is the same as when you uninstall a Service Pack. See Uninstall Transfer CFT.
How to free disk space from service packsThis topic describes how to reclaim disk space that is taken up by Service Packs and updates applied to Transfer CFT over time.
Use the purge commandUse the purge command followed by the appropriate options to removed accumulated backups of installed Transfer CFT updates.
1. Navigate to the Transfer CFT installation directory.
2. Run the purge command as described in the following sections.
Syntax
purge [-h | --help] | [-k | --keep] [number] [-p | --pretend]
l UNIX: purge.sh
Where:
l [-h | --help]: Displays the command help.
l [-k | --keep] [number]: Specifies the number of updates that should be kept.
l [-p | --pretend]: Previews the action to be done.
Examples
Transfer CFT 3.3.2 Installation Guide 88
Keep only the last backup, meaning you can remove the current patch or SP.
<Transfer_CFT_install_dir>/purge.sh -k 1
Remove all backups, meaning that you cannot remove the current patch or SP.
<Transfer_CFT_install_dir>/purge.sh -k 0
<Options> include:
l [-d | --debug]: Generates debug information in the log file.
Example
<Transfer_CFT_install_dir>/purge.sh -k 1 -d
Perform a standard migration
Migration prerequisitesAfter performing a Transfer CFT 3.3.2 installation, you should update to the most recent service pack.
You require a new license key if you are migrating from a version 2.x Transfer CFT to a version 3.x.
Note You require as many keys as instances of Transfer CFT running at same time, including when running in multi-node. For example, two Transfer CFT instances cannot run at the same time, on the same server, using the same license key.
Check the TLS versionAs of Transfer CFT 3.2.0, the use of cipher suites 59, 60, and 61 is restricted to TLS 1.2 exclusively. This means that if some of your partners use a version of Transfer CFT lower than 3.2.0 that does not support TLS 1.2, and you are using ciphers 59, 60 and 61, which requires TLS 1.2 in version 3.2.0 and higher, you must add another cipher in the cipher list and remove ciphers 59, 60, 61 from the partner's cipher list.
Note You do not have to remove ciphers 59, 60, 61 in the partner cipher list if you apply the Transfer CFT patch 3.0.1 SP11.
CA certificate chainsIn Transfer CFT 3.1.3 and lower, you can perform a SSL transfer even if the certificate chain is not complete (not signed by a ROOT CA). However, for Transfer CFT 3.2.0 and higher, the certificate chain must be complete for a transfer to succeed.
For more information, see Unknown CA leads to a failed certificate verification.
Transfer CFT 3.3.2 Installation Guide 89
Install Transfer CFT 3.3.2Perform a Transfer CFT installation, as described in the OS-specific installation section.
Note Do not use the Install auto-import option available in the Installer.
Load the environment Before beginning a standard migration procedure, you must load the old Transfer CFT environment.
UNIX procedure
Transfer CFT 2.3.2 and 2.4
From the console, execute the profile file for your version of Transfer CFT, which is by default located in the home directory. Enter: . ./ENV_CFT
Transfer CFT 2.5 and higher
From the console, change directory to the Transfer CFT runtime directory and execute the profile file using the command: . ./profile
After loading the profile, you can execute commands from anywhere.
Install and auto import The install and auto import option allows you to preform a new Transfer CFT installation and import configuration files and data from a existing Transfer CFT instance. During the procedure, you can select options for your new instance, and additionally can select which of the available types of data and configuration elements that you want to import.
Note Previous versions that are available for auto importing the configuration data include v2.3.2, 2.4, v2.5, v2.6, v2.7, v3.0.1, v3.1.x, and v3.2.x.
To check the Transfer CFT version, as well as the license key and system information, enter the command:
CFTUTIL ABOUT
You require a new license key if you are migrating from a version 2.x Transfer CFT to a version 3.x.
ProcedureRun the installer to perform a new Transfer CFT installation. During this process you are prompted with the option of importing existing data and configuration.
Transfer CFT 3.3.2 Installation Guide 90
Start your installationBegin a typical installation using the Transfer CFT 3.3.2 installation instructions that correspond to your operating system.
Importing configuration and dataPending the existing version of Transfer CFT, the installer will propose available import options.
Auto import screens
At this point you can select to migrate. The Installer page asks if you want to import data from your existing Transfer CFT instance. In the following screen you can select which types of data you'd like to import.
1. Select Yes to perform an automatic migration. Click Next.
2. Enter or navigate to the path for the existing profile file (profile.bat or profile.sh) for version 2.5 and higher. The profile file should be located in the runtime folder of the existing Transfer CFT installation.
3. Click to select configuration elements and objects that you want to import from the existing Transfer CFT instance. You must manually migrate execs, exits, and APIs.
Identity
1. You are prompted to confirm the local instance details. Modify if necessary, and click Next to continue.
2. Check the license key.
Post auto importIf you used the install and auto import procedure with your existing Transfer CFT to Transfer CFT 3.3.2, at the end of the installation a new directory called migration is created in the runtime directory. This directory stores all of the information used during the auto import process. You can modify the extracted files and/or directory, and manually re-import this data at any time.
The contents of this Auto import directory are described in the following table.
File Directory Description of extracted data
cftcat.xml Catalog file.
cftcom.xml Communication media.
cft-conf.cfg Transfer CFT general configuration, which is applied to the new installation (contained in CFTPARM/CFTPART internal datafiles).
Transfer CFT 3.3.2 Installation Guide 91
File Directory Description of extracted data
cft-conf-warning.txt
Contains file path declarations from the cft-conf.cfg file that were used in the former Transfer CFT environment and that cannot be imported into the new installation.
cft-pki.cfg The PKI configuration that is applied to the new installation (as of version 2.4).
PKI directory Contains extracted SSL certificates (pending version).
cft-uconf.(sh/bat)
Contains:
l UCONF parameters (as of V2.5.1)
or
l Sentinel parameters (TRKAPI.cfg - V2.3.2 and V2.4.x)
and/or
l Copilot parameters (copconf.ini - V2.4.x)
This file is used to set the new installation UCONF parameters.
cft-uconf-warning.txt
Contains UCONF parameters set by the user in the former Transfer CFT environment and that cannot be imported into the new installation.
migration.(sh/bat)
Contains instructions on how to re-import the collected data into a new installation, and includes the PKI, general configuration, UCONF parameters, catalog and communication media files.
Auto import in multi-node architecture This section describes how to proceed to use auto import for Transfer CFT 3.0.1, 3.1.3, or 3.2.x multi-node in multi-hosts.
ProcedureOn the first host:
Transfer CFT 3.3.2 Installation Guide 92
The automatic import is performed during the Transfer CFT 3.3.2 installation. During the installation, dialog boxes let you select configuration data from the existing Transfer CFT to import.
While installing first node on cluster architecture, you should opt to import data from the previous Transfer CFT version. Execute the procedure as described here. During installation of additional nodes, the option of importing data from previous version of Transfer CFT should not be selected.
If you choose to migrate your existing Transfer CFT to 3.3.2 using the automatic import method, at the end of the installation a new directory called auto_import is created in the runtime directory. This directory stores all of the information used during the installation and auto import. You can modify the extracted files and/or directory, and manually re-import this data at any time.
If you are installing and performing an auto import from a Transfer CFT with multi-node architecture enabled, the contents of the Auto_import directory are as shown in the table below.
On additional hosts:
Repeat the installation steps, indicating the appropriate shared directories. See the information provided in Multi-node options on page 28.
Table 1. Auto_import directory
File Directory Description of extracted data
cftcatXX.xml Catalog files. XX represents the node number, from 00 to Total_Number_of_Nodes -1.
cftcom.xml Communication media for node manager.
cftcomXX.xml Communication media for nodes. XX represents the node number, from 00 to Total_Number_of_Nodes -1.
cft-conf.cfg Transfer CFT general configuration, which is applied to the new installation (contained in CFTPARM/CFTPART internal datafiles).
cft-conf-warning.txt
Contains file path declarations from the cft-conf.cfg file that were used in the former Transfer CFT environment and that cannot be imported into the new installation.
cft-pki.cfg The PKI configuration that is applied to the new installation, as of version 2.4.
PKI directory Contains extracted SSL certificates (pending version).
Transfer CFT 3.3.2 Installation Guide 93
File Directory Description of extracted data
cft-uconf.(sh/bat)
Contains:
l UCONF parameters (as of V2.5.1)
- or -
l Sentinel parameters (TRKAPI.cfg - V2.3.2 and V2.4.x)- and/or -
l Copilot parameters (copconf.ini - V2.4.x)
This file is used to set the new installation UCONF parameters.
cft-uconf-warning.txt
Contains UCONF parameters set by the user in the former Transfer CFT environment and that cannot be imported into the new installation.
migration.(sh/bat)
Contains instructions on how to re-import the collected data into a new installation, and includes the PKI, general configuration, UCONF parameters, catalog and communication media files.
Migrating from Transfer CFT 2.3.2 to 3.3.2This topic describes how to migrate Transfer CFT 2.3.2 to 3.3.2.
Migrating the configuration
Migrating the main configurationMigrate PARM, PART, IDF and other static configuration objects.
1. Load the Transfer CFT 2.3.2 environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the Transfer CFT 3.3.2 installation.
4. Load the Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 94
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating trkapi.cfg file parameters 1. In the trkapi.cfg file, select the parameters you want to import into 3.3.2.
2. Create a script file, for example:
o UNIX: trkapi-import.sh
3. For each parameter you select, add a UCONF command line to your new script file using the format: UCONFSET id=<parameter_id>, value=<value>
4. Use the parameter mapping between trkapi and UCONF, as listed in the following table, to specify the correct parameter id.
Table 2. Parameter mapping between the trkapi.cfg file and UCONF
Parameter in trkapi.cfg Parameter names in UCONF
TRACE sentinel.trktrace
TRKGMTDIFF sentinel.trkgmtdiff
TRKIPADDR_BKUP sentinel.trkipaddr_bkup
TRKIPPORT sentinel.trkipport
TRKIPPORT_BKUP sentinel.trkipport_bkup
TRKLOCALADDR sentinel.trklocaladdr
TRKPRODUCTNAME sentinel.trkproductname
XFB.BufferSize sentinel.xfb.buffer_size
XFB.Log (UNIX) sentinel.xfb.log
XFB.Sentinel sentinel.xfb.enable
XFB.Trace sentinel.xfb.trace
XFB.Transfer sentinel.xfb.transfer
Load the Transfer CFT 3.3.2 environment.
5. Import the selected UCONF parameters using the command CFTUTIL. Replace <script_filename> with the new script file path: CFTUTIL <prefix_character><script_filename>
Transfer CFT 3.3.2 Installation Guide 95
Example
l UNIX: CFTUTIL @trkapi-import.sh
Migrating PKI certificatesExporting PKI certificates from Transfer CFT 2.3.2 is not supported. For this reason, you must create a new PKI database in the Transfer CFT 3.3.2 runtime using the PKIUTIL PKIFILE command. Next import each certificate using the PKIUTIL PKICER command.
For more information, refer to the Transfer CFT 3.3.2 User's Guide, sections Using the PKIFILE command and Using the PKICER command.
Migrating the runtime environment
Migrating the catalog 1. Load the Transfer CFT 3.3.2 environment.
2. Export the catalog using the command CFTMI230:
CFTMI230 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.3.2_filename>,
ofname=catalog_output.xml
3. Import the catalog using the command CFTMI. Replace the <catalog_filename_new_installation> with the corresponding environmental variable:
o UNIX: _CFTCATA
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml,
ofname=<catalog_filename_new_installation>
Migrating the communication media files 1. Load the Transfer CFT 3.3.2 environment.
2. Export the communication media file using command CFTMI230:
CFTMI230 MIGR type=COM, direct=FROMCOM, ifname=<com_2.3.2_filename>, ofname=com_output.xml
3. Import the communication media file using command CFTMI. Replace the <com_filename_new_installation> with the system-specific environment variable:
o UNIX: _CFTCOM
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_
filename_new_installation>
Transfer CFT 3.3.2 Installation Guide 96
Migrating from Transfer CFT 2.4 to 3.3.2This topic describes how to migrate from Transfer CFT 2.4 to version 3.3.2. Before starting this migration procedure you must perform the steps described in Before you start.
Migrating the configuration
Migrating the main configurationMigrate PARM, PART, IDF and other static configuration objects.
1. Load the Transfer CFT 2.4 environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter: CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the Transfer CFT 3.3.2 installation.
4. Load the Transfer CFT 3.3.2 environment.
5. Stop Transfer CFT if you have not already done so.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating trkapi.cfg file parametersMigrate the parameters from the Transfer CFT 2.4 trkapi.cfg file.
1. In the trkapi.cfg file, select the parameters you want to import in 3.3.2.
2. Create a script file, for example:
o UNIX: trkapi-import.sh
3. For each parameter you select, add a UCONF command line to your new script file using the format:
UCONFSET id=<parameter_id>, value=<value>
Use the parameter mapping between trkapi and UCONF, as listed in the following table, to specify the correct parameter id.
Transfer CFT 3.3.2 Installation Guide 97
Table 3. Parameter mapping between the trkapi.cfg file and UCONF
Parameter in trkapi.cfg Parameter names in UCONF
TRACE sentinel.trktrace
TRKGMTDIFF sentinel.trkgmtdiff
TRKIPADDR_BKUP sentinel.trkipaddr_bkup
TRKIPPORT sentinel.trkipport
TRKIPPORT_BKUP sentinel.trkipport_bkup
TRKLOCALADDR sentinel.trklocaladdr
TRKPRODUCTNAME sentinel.trkproductname
XFB.BufferSize sentinel.xfb.buffer_size
XFB.Log (UNIX) sentinel.xfb.log
XFB.Sentinel sentinel.xfb.enable
XFB.Trace sentinel.xfb.trace
XFB.Transfer sentinel.xfb.transfer
4. Load the Transfer CFT 3.3.2 environment.
5. Import the selected UCONF parameters using the command CFTUTIL. Replace <script_filename> with the new script file path.
CFTUTIL <prefix_character><script_filename>
Example
l UNIX: CFTUTIL @trkapi-import.sh
Migrating copconf.ini parametersMigrate parameters from the Transfer CFT 2.4 copconf.ini file.
1. From the copconf.ini file, select the parameters you want to import into version 3.3.2.
2. Create a script file, for example:
o UNIX: copconf-import.sh
3. For each selected parameter add a UCONF command line in your new script file using the format:
UCONFSET id=<parameter_id>, value=<value>
Transfer CFT 3.3.2 Installation Guide 98
Use the parameters mapping between copconf and UCONF as listed in the following table to specify the correct parameter id.
Table 4. Parameter mapping between copconf file and UCONF
Parameter in copconf.ini Parameter name in UCONF
BatchList copilot.batches
CFTCOM copilot.cft.com
CFTMEDIACOM copilot.cft.mediacom
ChildProcessTimeout copilot.misc.childprocesstimeout
HttpRootDir copilot.http.httprootdir
MinNbProcessReady copilot.misc.minnbprocessready
NbProcessToStart copilot.misc.nbprocesstostart
NBWAITCFTCATA copilot.cft.nbwaitcftcata
ServerHost copilot.general.serverhost
ServerPort copilot.general.serverport
SslCertFile copilot.ssl.sslcertfile
SslCertPassword copilot.ssl.sslcertpassword
SslKeyFile copilot.ssl.sslkeyfile
SslKeyPassword copilot.ssl.sslkeypassword
TcpTimeout copilot.misc.tcptimeout
TIMERWAITCFTCATA copilot.cft.timerwaitcftcata
TrcMaxLen copilot.trace.trcmaxlen
TrcType copilot.trace.trctype
wlogComment copilot.batches.wlog.comment
wlogParams copilot.batches.wlog.params
WsiComplience copilot.webservices.wsicomplience
4. Load the Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 99
5. Import the selected UCONF parameters using the command CFTUTIL. Replace the <script_filename> with the new script file path.
CFTUTIL <prefix_character><script_filename>
Example
l UNIX: CFTUTIL @copconf-import.sh
Migrating PKI certificatesYou must be at Transfer CFT 2.4.1 SP5 or higher before performing this procedure.
1. Load the Transfer CFT 2.4 environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the new Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate variable:
o UNIX: $CFTPKU
PKIUTIL PKIFILE fname=<pki_database_filename>, mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <script_filename> with the new script file path.
PKIUTIL <prefix_character><script_filename>
Example
l UNIX: PKIUTIL @pki-extract.conf
Migrating the runtime environment
Migrating the catalog 1. Load the Transfer CFT 2.4 environment.
2. Export the catalog using the command CFTMI240:
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.4_filename>, ofname=catalog_output.xml
3. Load the Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 100
4. Import the catalog using the command CFTMI. Replace the <catalog_filename_new_installation> with the corresponding environment variable:
o UNIX: _CFTCATA
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=<catalog_filename_new_installation>
Migrating the communication media files 1. Load the Transfer CFT V2.4 environment.
2. Export the communication media file using command CFTMI240:
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_2.4_filename>, ofname=com_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace <com_filename_new_installation> with the corresponding environment variable:
o UNIX: _CFTCOM
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_
filename_new_installation>
Migrate from Transfer CFT 2.5 or 2.6 to 3.3.2This topic describes how to migrate Transfer CFT 2.5 or 2.6 to version 3.3.2.
Migrate the configuration
Migrating the main configurationMigrate PARM, PART, IDF and other static configuration objects.
1. Load the former Transfer CFT (2.5 or 2.6) environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load the new Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 101
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command.
Enter:
cftinit cft-extract.conf
Migrating UCONF parameters 1. Load the former Transfer CFT (2.5 or 2.6) environment.
2. Display your UCONF parameters using the CFTUTIL LISTUCONF command. Enter: CFTUTIL LISTUCONF scope=user
3. Select the UCONF parameters that you want to import into the new Transfer CFT 3.3.2.
4. Create a script file such as:
l UNIX: uconf-import.sh
5. For each parameter you select, add a line to the new script file in the format:
UCONFSET id=<parameter_id>, value=<value>
6. Load the new Transfer CFT 3.3.2 environment.
7. Import the selected UCONF parameters using the script file and the CFTUTIL command. Replace the <script_filename> with the new script file path:
CFTUTIL <prefix_character><script_filename>
Example
l UNIX: CFTUTIL @uconf-import.sh
Migrating PKI certificatesFor Transfer CFT 2.5, you must be at Transfer CFT 2.5.1 SP2 or higher before performing this procedure. For Transfer CFT 2.6.4, you must be at Transfer CFT 2.6.4 SP2 or higher before performing this procedure.
1. Load the former Transfer CFT environment (2.5 or 2.6).
2. Export your PKI certificates using the command PKIUTIL PKIEXT: PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the new Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate value: PKIUTIL PKIFILE fname=<pki_database_filename>, mode='CREATE’
l UNIX: $CFTPKU
Transfer CFT 3.3.2 Installation Guide 102
5. Import your PKI certificates into the new Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <script_filename> with the new script file path: PKIUTIL <prefix_character><script_filename>
Example
l UNIX: PKIUTIL @pki-extract.conf
Migrating the runtime environment
Migrating the catalog 1. Load the former Transfer CFT (2.5 or 2.6) environment.
2. Export the catalog using the command CFTMI240.
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.5_filename>,
ofname=catalog_output.xml
3. Load the new Transfer CFT 3.3.2 environment.
4. Import the catalog using the command CFTMI. Replace the <catalog_filename_new_installation> with the corresponding environment variable:
l UNIX: _CFTCATA
Table 5. Example
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml,
ofname=<catalog_filename_new_installation>
Migrating the communication media files 1. Load the former Transfer CFT (2.5 or 2.6) environment.
2. Export the communication media file using command CFTMI240:
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_2.5_filename>, ofname=com_output.xml
3. Load the new Transfer CFT 3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace the <com_filename_new_installation> with the corresponding environment variable:
o UNIX: _CFTCOM
Transfer CFT 3.3.2 Installation Guide 103
Table 6. Example
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_
filename_new_installation>
Migrating Transfer CFT 2.6.4 SP2 or 2.7 to 3.3.2This topic describes how to migrate Transfer CFT 2.6.4 SP2, or higher, or 2.7 to version 3.3.2.
Migrating the main configuration and UCONF parametersYou can migrate the PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load the former Transfer CFT environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load the new Transfer CFT 3.3.2 environment.
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating PKI certificates 1. Load the former Transfer CFT (2.6.4 or 2.7) environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the new Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 104
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the OS appropriate value:
UNIX: $CFTPKU
5. Import your PKI certificates into the new Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <script_filename> with the new script file path:
PKIUTIL <prefix_character><script_filename>
Examples
UNIX: PKIUTIL @pki-extract.conf
Migrating the runtime environment
Migrating the catalog 1. Load the former Transfer CFT (2.6.4 or 2.7) environment.
2. Export the catalog using the command CFTMI240:
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.7_filename>, ofname=catalog_output.xml
3. Load the new Transfer CFT 3.3.2 environment.
4. Import the catalog using the command CFTMI. Replace the <catalog_filename_new_installation> with the corresponding environment variable:
UNIX: _CFTCATA
Example
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml,
ofname=<catalog_filename_new_installation>
Migrating the communication media files 1. Load the former Transfer CFT (2.6.4 or 2.7.0) environment.
2. Export the communication media file using command CFTMI240:
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_
2.7.0_filename>, ofname=com_output.xml
3. Load the new Transfer CFT3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace the <com_filename_new_installation> with the corresponding environment variable:
UNIX: _CFTCOM
Transfer CFT 3.3.2 Installation Guide 105
Example
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_
filename_new_installation>
Migrating Transfer CFT 3.0.1 or 3.1.x to 3.3.2This topic describes how to migrate Transfer CFT 3.0.1 or 3.1.2 to version 3.3.2. It is divided in 2 sections, the first section describes migration for a single node architecture, and the second section multi-node architecture. Lastly there are instructions explaining what would be needed to migrate from single node architecture to multi node architecture.
Note When migrating from 3.0.1 to 3.3.x, you must install SP10 P6 on all Transfer CFTs v3.0.1 that inter-operate with any Transfer CFTs v3.3.x prior to migrating.
Single node architecture
Migrating the configuration
Migrating the main configuration and UCONF parameters
Migrate PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load former Transfer CFT 3.0.1 or 3.1.x environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load Transfer CFT 3.3.2 environment.
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating PKI certificates 1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
Transfer CFT 3.3.2 Installation Guide 106
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate value: $CFTPKU for UNIX, the absolute path value for the CFTPKU for Windows. Enter:
PKIUTIL PKIFILE fname=<pki_database_filename>,
mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <prefix_character> based on your system, @ for UNIX and # for Windows. Enter:
PKIUTIL <prefix_character>pki-extract.conf
Migrating the runtime environment
Migrating the catalog
1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export the catalog using the command CFTMI. Replace the <catalog_filename > with the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_
filename_former_cft>, ofname=catalog_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the catalog using the command CFTMI. Replace the <catalog_filename > with the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_
output.xml, ofname=<catalog_filename_new_cft >
Migrating the communication media files
1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export the communication media file using command CFTMI. Replace the <com_filename > with the corresponding environment variable, _CFTCOM for UNIX, or $CFTCOM for Windows. Enter:
Transfer CFT 3.3.2 Installation Guide 107
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_
filename_former_cft>, ofname=com_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace the <com_filename > with the corresponding environment variable, _CFTCOM for UNIX or $CFTCOM for Windows. Enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml,
ofname=<com_filename_new_cft >
Executables and binaries
Remember that you can copy your post-processing scripts directly from the runtime/exec to the new version (3.3.2). When you copy files from the exec folder, be certain to modify any paths that point to the former version (for example, 3.0.1, 3.1.3 or 3.2.x). However, you must rebuild APIs and EXITS (binaries).
Multi-node architecture
Migrating the configuration
Migrating the main configuration and UCONF parameters
Migrate PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load Transfer CFT 3.3.2 environment.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Transfer CFT 3.3.2 Installation Guide 108
Migrating PKI certificates 1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter: PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate value, $CFTPKU for UNIX or the absolute path value for the CFTPKU for Windows. Enter:
PKIUTIL PKIFILE fname=<pki_database_filename>,
mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <prefix_character> based on your system, @ for UNIX and # for Windows. Enter:
PKIUTIL <prefix_character>pki-extract.conf
Migrating the runtime environment
Migrating the catalog
1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export all catalogs (one per node, named as cftcataXX, where XX is the node number with range from 00 to <number of nodes - 1>) using the command CFTMI. For each catalog. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT,
ifname=<catalog_filename_former_cft_for_node_
<node>>, ofname=catalog_output_<node>.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import all catalogs using the command CFTMI for each of them. Use the same node number on both <node> on command. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output_
<node>.xml, ofname=<catalog_filename_new_cft><node>
Transfer CFT 3.3.2 Installation Guide 109
Migrating the communication media files
1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
2. Export all communication media files (cftcom and cftcomXX, where XX is the node number with range from 00 to <number of nodes - 1>) using the command CFTMI. For each communication media file.
l Enter: CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_node_manager_on_former_cft>, ofname=com_output.xml
l For each node, enter: CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_node_<node>_on_former_cft>, ofname=com_output_<node>.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import all communication media files using command CFTMI for each of them. Use the same node number on both <node> on command.
l Enter: CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_filename_for_node_manager_on_new_cft>
l For each node, enter: CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput_<node>.xml, ofname=<com_filename_for_node_<node>_on_new_cft>
Single-node to multi-node architecture migrationThe only difference between migrating from single node to multi-node architecture and migrating from single-node to single-node architecture is the catalog migration step. Since there is no catalog named cftcata in multi-node, import the catalog exported from single-node architecture to the catalog of any of the nodes in the multi-node architecture.
Migrating Transfer CFT 3.2.x to 3.3.2This topic describes how to migrate Transfer CFT 3.2.x (either 3.2.2 or 3.2.4) to version 3.3.2. It is divided in 2 sections, the first section describes migration for a single node architecture, and the second section multi-node architecture. Lastly there are instructions explaining what would be needed to migrate from single node architecture to multi node architecture.
Single node architectureStop Transfer CFT and the Copilot server before starting the migration.
Transfer CFT 3.3.2 Installation Guide 110
Migrating the configuration
Migrating the main configuration and UCONF parameters
Migrate PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load former Transfer CFT 3.2.x environment. See the Migration prerequisites on page 89 for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load Transfer CFT 3.3.2 environment.
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating PKI certificates 1. Load former Transfer CFT 3.2.x environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Copy all files that are referenced in the pki-extractconf file (INAME OR IKNAME) to the folder where you are going to execute the PKI command on the new version. In the following example, copy ROOT0001 to the new folder in Transfer CFT 3.3.2.
PKICER ID = 'LOCALROOT',
ROOTCID = 'LOCALROOT',
ITYPE = 'ROOT', /*
PKIFNAME = '',*/ /*
COMMENT = '',*/
INAME = 'ROOT0001',
IFORM = 'DER', /*
IKNAME = '',*/ /*
IKFORM = '',*/ /*
FOUT = '',*/
MODE = 'REPLACE'
4. Load the Transfer CFT 3.3.2 environment.
Transfer CFT 3.3.2 Installation Guide 111
5. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate value: $CFTPKU for UNIX, the absolute path value for the CFTPKU for Windows. Enter:
PKIUTIL PKIFILE fname=<pki_database_filename>, mode='CREATE’
6. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <prefix_character> based on your system, @ for UNIX and # for Windows. Enter:
PKIUTIL <prefix_character>pki-extract.conf
Migrating the runtime environment
Migrating the catalog
1. Load former Transfer CFT 3.2.x environment.
2. Export the catalog using the command CFTMI. Replace the <catalog_filename > with the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_filename_
former_cft>, ofname=catalog_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the catalog using the command CFTMI. Replace the <catalog_filename > with the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml,
ofname=<catalog_filename_new_cft >
Migrating the communication media files
1. Load former Transfer CFT 3.2.x environment.
2. Export the communication media file using command CFTMI. Replace the <com_filename > with the corresponding environment variable, _CFTCOM for UNIX, or $CFTCOM for Windows. Enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_
former_cft>, ofname=com_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace the <com_filename > with the corresponding environment variable, _CFTCOM for UNIX or $CFTCOM for Windows. Enter:
Transfer CFT 3.3.2 Installation Guide 112
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml,
ofname=<com_filename_new_cft >
Executables and binaries
Remember that you can copy your post-processing scripts directly from the runtime/exec to the new version (3.3.2). When you copy files from the exec folder, be certain to modify any paths that point to the former version (3.2.x in this case). However, you must rebuild APIs and EXITS (binaries).
Migrate a multi-node to multi-node architecture
Migrating the configurationStop Transfer CFT and the Copilot server before starting the migration.
Migrating the main configuration and UCONF parameters
Migrate PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load former Transfer CFT 3.2.x environment.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation.
4. Load Transfer CFT 3.3.2 environment.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating PKI certificates 1. Load former Transfer CFT 3.2.x environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_database_filename> with the appropriate value, $CFTPKU for UNIX or the absolute path value for the CFTPKU for Windows. Enter:
Transfer CFT 3.3.2 Installation Guide 113
PKIUTIL PKIFILE fname=<pki_database_filename>, mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the <prefix_character> based on your system, @ for UNIX and # for Windows. Enter:
PKIUTIL <prefix_character>pki-extract.conf
Migrating the runtime environment
Migrating the catalog
1. Load former Transfer CFT 3.2.x environment.
2. Export all catalogs (one per node, named as cftcataXX, where XX is the node number with range from 00 to <number of nodes - 1>) using the command CFTMI. For each catalog. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_filename_former_cft_node_<node>>, ofname=catalog_output_<node>.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import all catalogs using the command CFTMI for each of them. Use the same node number on both <node> on command. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output_
<node>.xml, ofname=<catalog_filename_new_cft_node_<node>>
Migrating the communication media files
1. Load former Transfer CFT 3.2.x environment.
2. Export all communication media files (cftcom and cftcomXX, where XX is the node number with range from 00 to <number of nodes - 1>) using the command CFTMI.
For each communication media file, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_
node_manager_on_former_cft>, ofname=com_output.xml
For each node, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_
node_<node>_on_former_cft>, ofname=com_output_<node>.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import all communication media files using the CFTMI command.
Transfer CFT 3.3.2 Installation Guide 114
For the manager, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml,
ofname=<com_filename_for_node_manager_on_new_cft>
For each node, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput_<node>.xml,
ofname=<com_filename_for_node_<node>_on_new_cft>
Single-node to multi-node architecture migrationThe only difference between migrating from single node to multi-node architecture and migrating from single-node to single-node architecture is the catalog migration step. Since there is no catalog named cftcata in multi-node, import the catalog exported from single-node architecture to the catalog of any of the nodes in the multi-node architecture.
Transfer CFT 3.3.2 Installation Guide 115
Activate Central Governance connectivityCentral Governance simplifies the management of Transfer CFT and provides identity and access management, certificate security services, monitoring, alerting, and web dashboard services. Central Governance replaces possible existing services from earlier Transfer CFT installations that required implementing and configuring multiple products, such as Transfer CFT Navigator, PassPort, and Composer.
You can perform this activation procedure only after completing an upgrade or migration to Transfer CFT 3.1.3 or higher.
OverviewThere are two ways to activate Transfer CFT to Central Governance connectivity following an upgrade procedure:
l Automatically activate connectivity on page 116
l on page 117
Additional information and tasks:
l Connect to a different Central Governance system on page 120
l Use former configuration objects on page 120
l View managed features on page 120
Automatically activate connectivityUNIX/Windows
The automatic activation is only available in UNIX/Windows. Please refer to Manually activate connectivity below for z/OS or IBM i instructions.
This section describes how to run the installer in configure mode to enable Central Governance connectivity.
PrerequisiteYou must set the UCONF parameter cg.configuration_policy if you want to override the default policy applied by Central Governance when you register a Transfer CFT in Central Governance.
Procedure 1. Stop Transfer CFT and Copilot.
2. Start the installer in configure mode.
GUI
Transfer CFT 3.3.2 Installation Guide 116
UNIX: configure.sh –m gui
Console
UNIX: configure.sh –m console
3. In the installer screen, select Configure your existing installation.
4. Enter the license key if required.
5. Accept or modify the UI server and service mode screen values.
6. In the Governance Mode screen, select Central Governance.
7. In the CG connectivity screen, enter the Central Governance values. For Transfer CFT z/OS installations, see Use compliant characters for the z/OS shared secret on page 119.
8. Click Next and complete the configure procedure.
9. Once completed, start Copilot, which automatically completes the registration process.
You can check in Central Governance to see that the Transfer CFT displays in the Product List.
Manually activate connectivityAll OS
This section describes how to manually modify the Transfer CFT configuration to enable Central Governance connectivity in command line.
Prerequisites 1. Stop Transfer CFT and Copilot if running.
2. Enabling Central Governance connectivity after an upgrade implies replacing any standalone connectors. Therefor, prior to connecting to Central Governance deactivate all previously activated connectors, for example PassPort AM, PassPort PS, and Sentinel.
CFTUTIL uconfunset id=am.type
CFTUTIL uconfunset id=sentinel.xfb.enable
CFTUTIL uconfset id=pki.type, value=cft
Note When running in a z/OS environment you must additionally set the am.passport.superuser with the user that will start the Copilot server.
3. Ensure that all UCONF values used to identify a Transfer CFT instance are defined. These parameters include:
l cft.full_hostname
l cft.instance_id
l cft.instance_group
Use the format:
Transfer CFT 3.3.2 Installation Guide 117
CFTUTIL uconfset id=cft.instance_id, value=<cft_id>
You must set the UCONF parameter cg.configuration_policy if you want to override the default policy applied by Central Governance when you register a Transfer CFT in Central Governance.
ProcedureThe manual procedure consists of the following steps, which are detailed below:
1. Include certificates in the PKI database.
2. Set the UCONF parameter values for Central Governance.
3. Enable Central Governance.
4. Start Copilot.
Include certificatesYou must include the certificate authority that is used to validate communication with Central Governance in the PKI database. You can personalize this certificate on the Central Governance side, so be sure to use the correct iname in the pkicer command.
You can use any ID for this certificate. Transfer CFT uses the certificate ID defined in UCONF to communicate with Central Governance.
Note Modify the filename syntax to accommodate your specific platform.
PKIUTIL pkicer id = 'CG_CA',
iform = 'PEM',
iname = '$CFTPKIDIR/passportCA.pem',
itype = 'ROOT',
pkifname = '$CFTPKU',
pkipassw = 'CFT',
state = 'ACT',
mode = 'CREATE'
After inserting the correct certificate in the PKI database, define the UCONF variable cg.ca_cert_id. This value is required so that Transfer CFT knows which certificate to use when communicating with Central Governance.
CFTUTIL uconfset id=cg.ca_cert_id, value='CG_CA'
Set UCONF valuesUse the Central Governance installation values for the following UCONF settings. Transfer CFT uses these values to identify Central Governance.
Transfer CFT 3.3.2 Installation Guide 118
l cg.host
l cg.port
l cg.mutual_auth_port
l cg.shared_secret
Use the format:
CFTUTIL uconfset id=cg.host, value=<host_value>
Enable Central Governance
CFTUTIL uconfset id=cg.enable, value=yes
RegisterStart the Transfer CFT Copilot to trigger an automatic registration with Central Governance.
You can check in the Central Governance Product List to confirm that the registration was successful.
On Transfer CFT z/OS
Use compliant characters for the z/OS shared secretWhen setting the Central Governance "shared secret" during a Transfer CFT z/OS installation, translation issues may occur if you use certain characters. For example, if you enter !SECRET (using code page IBM-1147) the shared secret is translated to §SECRET during the Central Governance registration. Therefore, you must use compliant characters in the shared secret value when working in a z/OS environment.
Verify the UCONF settingPrior to the registration, you must ensure that the JCL CFTMON (copilot.misc.cftstart.enable = Yes) is configured to match the jobname or the STC name used to launch Transfer CFT.
Use compliant characters for the z/OS shared secret
Use a proxy server between Transfer CFT and Central GovernanceTo use a proxy server between Transfer CFT and Central Governance, set the following Transfer CFT proxy parameters prior to registering with Central Governance:
Transfer CFT 3.3.2 Installation Guide 119
l cg.proxy.in.host
l cg.proxy.in.port
l cg.proxy.in.login
l cg.proxy.in.password
See UCONF: Central Governance options for details.
Connect to a different Central Governance systemIf Transfer CFTwas previously registered on a Central Governance system but you now want to register it on a different one, perform the steps in Manually activate connectivity and as a final step, prior to starting Copilot, reset the Central Governance registration id.
CFTUTIL uconfunset id=cg.registration_id
Use former configuration objectsIn Central Governance you can use the Legacy Flows feature to view and use an imported configuration. For more information, please refer to the Central Governance documentation.
View managed featuresAfter successfully upgrading and activating Central Governance connectivity, you can manage the following Transfer CFT features from Central Governance. The "Supported but not configurable" column lists features that you can retain, though you cannot manage them from the Central Governance interface.
Feature Manage using Central Governance
Supported but not configurable using Central Governance
Folder monitoring yes yes
Multi-node architecture no yes
CRONJOB no yes
Exits no yes
Network features
IPv6 yes yes
Transfer CFT 3.3.2 Installation Guide 120
Feature Manage using Central Governance
Supported but not configurable using Central Governance
pTCP (UNIX/Windows only) yes yes
UDT (UNIX/Windows only) yes yes
SOCKS no yes
Heartbeat embedded yes
Interoperability
Secure Relay no yes
TrustedFile no yes
PassPort AM embedded no (*)
PassPort PS no yes
Sentinel embedded yes
Composer no no
Protocols
PeSIT yes yes
ODETTE no yes
EBICS no yes
* If you perform a migration or upgrade from a previous version, you must migrate your PassPort AM.
Post-migration procedure
Post manual migration or auto importIf you performed an install and auto import or a manual migration, you must manually import compiled objects and exec scripts from the old configuration. There are no Transfer CFT commands to import these compiled objects and exec scripts, and they are not included in the auto import process.
Note After completing an upgrade or a migration procedure, you must update to the most recent SP.
Transfer CFT 3.3.2 Installation Guide 121
Compiled objects: APIs and ExitsTo manually migrate your API and exit binary files after migrating, copy your program's source code to the new Transfer CFT 3.3.2 runtime directory and compile them.
1. Copy the API source code to <new_Transfer CFT_3.3.2_installation_dir>/runtime/src/capi and compile.
2. Copy the Exit source code to <new_Transfer CFT_3.3.2_installation_dir>/runtime/src/exit and compile.
Exec scriptsCopy the exec scripts to <new_Transfer CFT_3.3.2_installation_dir>/runtime/exe. It is important that you update any paths that you were using in the exec scripts to reflect the new installation directory.
Post-manual migration only
Migrating UCONF parameters from a previous Transfer CFT versionYou must manually migrate UCONF parameters for versions prior to Transfer CFT 2.5.1. The UCONF configuration replaces the following configuration files:
l Sentinel configuration file (trkapi.cfg, trkapi.conf, and so on...)The parameters in the Sentinel file are integrated in UCONF as sentinel.FORMER-PARAMETER-NAME. For example, TRKTNAME becomes sentinel.TRKTNAME.
l Copilot ini file (copconf.ini) This file no longer exists. All former Copilot parameters are named copilot.SECTION.PARAMETER-NAME in the UCONF interface. For example, the parameter ServerPort, located in the general section, is now copilot.general.serverport.
l The profile file, formerly ENV_CFT or cft.ini, now uses UCONF to set the environment variables.
Post upgradeIf you performed an upgrade, you need only recompile your APIs and Exits.
Transfer CFT 3.3.2 Installation Guide 122
5 Uninstall
This topic describes how to uninstall Transfer CFT. If you uninstall a Transfer CFT, you will lose the complete Transfer CFT configuration. To avoid this, save your environment (sample, exit, …) before removing the Transfer CFT.
Before you begin uninstalling, you must stop the servers you want to uninstall.
1. You can run the installer in uninstall mode using GUI or console mode as follows. Enter:
GUI mode
UNIX/Linux: uninstall.sh –m gui
Console mode
UNIX/Linux: uninstall.sh –m console
1. Click Uninstall when prompted. A warning message displays; click Yes to continue with the uninstall.
2. Click Next to see the uninstall summary, and Finish to exit.
Transfer CFT 3.3.2 Installation Guide 123
5 Uninstall
124 Installation Guide Transfer CFT 3.3.2
6 Troubleshooting
Troubleshoot installation and registrationThis section lists some possible post-installation issues along with corresponding corrective actions when applicable. If corrective actions do not remedy the issue, check the Support tools section for more information, or contact support at support.axway.com.
Copilot server issues
Copilot doesn't start l Check that the port is not already used by another application.
l Close all active sessions, use the syntax: copstop -f
l Check that there are no orphan "cop*" processes. If there are, manually kill these processes.
Central Governance
Troubleshoot the registrationIf Copilot starts, but the Transfer CFT either does not display in the Central Governance Product List or registers in error:
l Verify the Central Governance IP address (or FQDN) used in the Transfer CFT configuration.
l On the computer running Transfer CFT, check that you can reach Central Governance at the IP address used in the Transfer CFT configuration.
l Check that the Transfer CFT appears in the Central Governance logs. If not, typically this is because the Transfer CFT is unable contact Central Governance.
l In Central Governance check Administration > Services to ensure that Central Governance is correctly started.
l Verify the shared secret for Central Governance used in the Transfer CFT configuration.
Note See the Central Governance documentation for additional information and details.
Transfer CFT 3.3.2 Installation Guide 125
6 Troubleshooting
Re-register with Central GovernanceWhen Central Governance sends the SSL certificates to Transfer CFT, the uconf:cg.registration_id parameter is set to a positive integer. If an error occurs, the registration process ends in error. To repeat the registration, perform the following steps:
1. Stop Transfer CFT.
2. Stop Copilot.
3. Set the uconf:cg.registration_id to its default value (-1) using the command:
CFTUTIL uconfunset id=cg.registration_id
4. Start the Transfer CFT Copilot. Copilot starts the registration process.
More information
For more information on Central Governance, refer to the Central Governance1.1.3 documentation.
Transfer CFT server
Cannot start my Transfer CFT l Check your Transfer CFT log in Central Governance.
l From the local Transfer CFT runtime, try to manually start the server. If you cannot manually start the server, refer to Support tools in the Transfer CFT User Guide.
Apply a license keyYou need to apply a valid license key to Transfer CFT in the following situations:
l You perform an initial Transfer CFT installation.
l To replace an expired license key (typically after a year).
l A hardware upgrade changes the CPU ID (only applicable on certain UNIX).
Transfer CFT 3.3.2 Installation Guide 126
6 Troubleshooting
Obtain a license key 1. Install Transfer CFT. You can install Transfer CFT without a license key, and enter the key later.
2. After completing the installation, or for an existing installation, use the command cftutil about to retrieve your system information.
Note Use the ABOUT command to display the Transfer CFT product, host, and key information. This command displays the characteristics of the platform on which Transfer CFT is installed.
3. Contact the Axway Fulfillment team at the appropriate email address to obtain a valid key.
l For a US key, contact: [email protected]
l For an EMEA or APAC key, contact: [email protected]
4. Provide the hostname and system information for the installed or updated Transfer CFT.
Apply a license keyNormally you enter the key that you received from the Axway Fulfillment team during the installation process. However, to apply the license key at a later date, enter the key(s) in the indirection file, which is referred to in the CFTPARM KEY parameter. See the KEY parameter for an example and details.
l The file can contain one or multiple license keys, but it must have one key per line.
l On start up the first valid key is used.
Multi-node keysTransfer CFT 3.3.2 SP2 and higher
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use a single key for multiple hosts, either:
l The hostname must not be defined for the key, or
l The hostname defined for the key matches the hostname of one of the hosts that composes the multi-node instance
Additionally, the key must have the cluster option.
For example, if you have 2 hosts and 4 nodes, you only need one key that matches one hostname (or no defined hostname).
Transfer CFT prior to 3.3.2 SP2
If you are using a Transfer CFT 3.3.2 prior to SP2, multi-node architecture requires:
l One key per node, and if there is more than one host you require at least one valid key per host
l Each key must have the cluster option
Transfer CFT 3.3.2 Installation Guide 127
6 Troubleshooting
For example, if you have 2 hosts and 4 nodes, you require 4 keys with at least one key per host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to reference to the second host
About commandUse the CFTUTIL utility to execute the about command to find the CPU ID and general system information as demonstrated in this example.
Host information :
* model = 4C
* hostname = rs58
* cpuid = F8C721F8C721F8C7
* sysname = AIX
* machine = 00F8C7214C00
* version = 7
* release = 1
* distrib = unknown
In this example, the CPU ID is F8C721F8C721F8C7. Your information, including the cpuid, will differ from the example.
Support tools /contact SupportThis section describes the tools available to help you collect information and contact support if you are unable to troubleshoot an error or issue.
Accessing the Axway Support siteIn the Axway Sphere Support web site, click to select Contact us for the email address and phone number of your nearest Axway support site.
Opening a Support caseBefore contacting Customer Support, we suggest that you start by using the Axway online patch library to see if there is a patch available for your problem, or by searching for a solution in the Knowledge Database. If you still need to contact Support, have the following information available if possible:
Transfer CFT 3.3.2 Installation Guide 128
6 Troubleshooting
l Product version
l Operating system
l cft_support
To submit a Support request, you can do the following:
l Submit and track your request through the Axway Support Web site support.axway.com.
l Each time you submit a support request, that request is assigned a unique number. Use this specific number when you contact Customer Support concerning that case.
l You must have a user account to submit a Support request.
Using cft_support The cft_support tool collects all of the needed information from the customer's Transfer CFT installation environment, including the static configuration (PARM/PART), Unified Configuration parameters (UCONF), catalog information, communication media file status (CFTCOM), log files, execution environment (variables), disk space, and so on. This information is then packaged into a archive file called cft-support-<date>(.tar.gz|.zip).
Note When using the cft_support tool on other Operating Systems, refer to the OS-specific guide for the correct syntax.
Using CopilotFrom the Copilot UI, click the debug icon. The report is saved in the Transfer CFT runtime directory, after which you are prompted to download the report to your desktop.
Using command lineIn command line, enter: cft_support collect [options]
Options:
l --help: Display this help and exit.
l --cat-filter: Filter the CFTUTIL LISTCAT output. See LISTCAT, or enter CFTUTIL HELP CMD=LISTCAT, to view available parameters.
l --cat-debug-filter: Filter the CFTUTIL LISTCAT CONTENT=DEBUG output. This option overrides --cat-filter.
l --no-core-analysis-gdb: Do not use gdb to analyze the cores. Unix only
l --no-core-analysis-dbx: Do not use dbx to analyze the cores. Unix only
Examples
Only collect information for a given transfer:
Transfer CFT 3.3.2 Installation Guide 129
6 Troubleshooting
cft_support collect --cat-filter="IDTU=A0000001"
Collect information for all transfers in error for a given partner:
cft_support collect --cat-filter="DIAGI=ERROR, PART=PARIS"
Collect transfer information related to a given IDF for all transfers in a brief LISTCAT, and only those transfers in error in a debug LISTCAT:
cft_support collect --cat-filter="IDF=BIN" --cat-debug-filter="IDF=BIN,
DIAGI=ERROR"
The command CFTSUPPORT executes a program located in CFTPGM. This program generates a tar file in the IFS environment with all the necessary information for Axway.
Note CFTSUPPORT is currently not supported with an independent ASP (IASP).
Note ATM traces are available only when using Transfer CFT Local Administration. However Central Governance managed Transfer CFT is the recommended version.
UNIX: Core dump recommendationsYou can use the ulimit command to set the size limitation for a core dump in Transfer CFT on UNIX systems. We recommend that you set the size of the core dump to 2GB.
Transfer CFT 3.3.2 Installation Guide 130
7 Unix operations
Running Transfer CFT for the first time UNIXThe elements and tasks required to start Transfer CFT for the first time include:
l Set the environment
l Start and stopping Transfer CFT
o Start using a command
o Shut down using a command
o Start or stop via a user interface
Set the environment After installing Transfer CFT , but before starting Transfer CFT you should:
l Execute the profile in the Transfer CFT runtime directory to define environment variables. Run: ‘. ./profile’
l Create a new set of Transfer CFT working files, parameters, partners, catalog, communication file, logs, use the sample configuration files cft-tcp.conf and cft-tcp-part.conf in the runtime/conf directory. You can configure these during the product installation, or manually after installation.
l Use cftinit <configuration_file> > and/or cftupdate to interpret the parameter and partner files.
cftinit conf/cft-tcp.conf
cftupdate conf/cft-tcp-part.conf
or
cftinit conf/cft-tcp.conf conf/cft-tcp-part.conf
Caution These commands generate an initial configuration by creating the configuration files. Any previous configurations, and any data in the communication file, catalog, or log files will be lost.
Sample file details
l cft-tcp.conf: Contains PARM object definitions (PARM, CAT, COM, LOG, ACCNT, PROT, SEND, RECV,...etc.)
Transfer CFT 3.3.2 Installation Guide 131
7 Unix operations
l cft-tcp-part.conf: Contains partner definitions (CFTPART, CFTTCP, CFTSSL)
Delivered partners are:
l PARIS - NEW YORK
l LOOP
l LOOPSSL0
Start and stop commandsThe following table lists the commands according to Transfer CFT version.
Version 2.7.1 and higher Version 2.7.0 and lower
cft start cftstart
cft stop cftstop
cft status cftstatus
cft force-stop cftstop -kill
cft force-stop –kill cftstop -forcedkill
Note The cftstart and cftstop commands, from version 2.7.0 and earlier, are redirected to the standardized commands for continued compatibility.
Start up You can start Transfer CFT with the cft start utility; see also Transfer CFT Management Utilities.
Shut down You can use one of the following methods to shut down Transfer CFT:
l The CFTUTIL utility
CFTUTIL shut fast=no
or
CFTUTIL shut fast=yes
l The cft utility
cft stop
For more information, see the administrative commands in Manage the Transfer CFT server.
Transfer CFT 3.3.2 Installation Guide 132
7 Unix operations
Start or stop via a user interfaceYou can also use either Central Governance or the Transfer CFT Copilot UI to start or shut down Transfer CFT.
Automatic Transfer CFT start on system start upThis section describes automatic Transfer CFT start procedures. However, the method used to run Transfer CFT when the system starts can vary according to the operating system. For more information on the various parameters' syntax, refer to your operating system documentation.
Because the time it takes to shut Transfer CFT down depends on the current workload, an automatic Transfer CFT shut down may cause the system shut down procedure to be temporarily suspended.
The examples in this section assume the following:
l Transfer CFT is installed in the cft user account
l Transfer CFT is installed as standard in the Axway/Transfer_CFT directory for this account
l In a multi-node environment, the Transfer CFT runtime is located in /mnt/axway/cft/runtime
l The home directory for this user is /home/cft
l Transfer CFT is correctly installed, configured, and manually tested before attempting any automatic activation procedure
Note The following sections refer to using a standard editor, for example, vi.
Using Systemd (Linux)Systemd is a system and service manager for Linux operating systems.
Define the Transfer CFT Copilot service (non multi-node)Use a standard editor to create the cftcopilot.service file in the /etc/systemd/system directory for a standalone installation as follows:
[Unit]
Description=Axway Transfer CFT Copilot
After=syslog.target network.target
[Service]
Type=forking
WorkingDirectory=/home/cft/Axway/Transfer_CFT/runtime
ExecStart=/bin/sh -c '. ./profile && copstart'
ExecStop=/bin/sh -c '. ./profile && copstop'
Group=cft
Transfer CFT 3.3.2 Installation Guide 133
7 Unix operations
User=cft
KillMode=process
[Install]
WantedBy=multi-user.target
Define the Transfer CFT service (non multi-node)
Use a standard editor to create the cft.service file in the /etc/systemd/system directory for a standalone installation as follows:
[Unit]
Description=Axway Transfer CFT
After=syslog.target network.target
[Service]
Type=forking
WorkingDirectory=/home/cft/Axway/Transfer_CFT/runtime
ExecStart=/bin/sh -c '. ./profile && cft start'
ExecStop=/bin/sh -c '. ./profile && cft stop'
Group=cft
User=cft
[Install]
WantedBy=multi-user.target
Define the Transfer CFT Copilot service (multi-node)
In a multi-node environment, you only need to define the Transfer CFT Copilot as a service. Copilot automatically starts the nodes. Use a standard editor to create the cftcopilot.service file in the /etc/systemd/system directory as follows:
[Unit]
Description=Axway Transfer CFT Copilot
After=syslog.target network.target
[Service]
Type=forking
WorkingDirectory=/mnt/axway/cft/runtime
ExecStart=/bin/sh -c '. ./profile && copstart && cft start'
ExecStop=/bin/sh -c '. ./profile && copstop -w'
Group=cft
User=cft
KillMode=process
[Install]
WantedBy=multi-user.target
Transfer CFT 3.3.2 Installation Guide 134
7 Unix operations
Once you have validated that the service starts and stops correctly, you can enable it for automatic starts.
Start a service
systemctl start <service_name>
Stop a service
systemctl stop <service_name>
Enable a service for automatic start
systemctl enable <service_name>
Disable a service
systemctl disable <service_name>
Using the /etc/inittab fileThis procedure is typically valid on all UNIX systems.
The following examples assume that the su() system utility is located in the /bin directory.
The start procedures in this section require you to update key system files. If errors are made, the system may no longer boot correctly, so the system administration should make these modifications.
You can use the logger() system command to store error messages displayed during an automatic start. For this to operate correctly, the syslogd() system daemon must be running on your system. The system administrator can identify the specific Transfer CFT messages in the system log files at the:
l Error level and the local0 facility for error messages
l Information level and the local0 facility for a correct start
Define the Transfer CFT service
Use a standard editor to add the following line at the end of the /etc/inittab file:
cft:2:once:/bin/su - cft -c ’. Axway/Transfer_CFT/runtime//profile; cft
start –batch’
Define the Transfer CFT Copilot service
Use a standard editor to add the following line to the end of the /etc/inittab file:
cftcopilot:2:once:/bin/su - cft -c ’. Axway/Transfer_
Transfer CFT 3.3.2 Installation Guide 135
7 Unix operations
CFT/runtime//profile; copstart’
Adding a file to /etc/rc2.dYou can only use this method on systems with a /etc/rc2.d directory (SOLARIS for example).
The following examples assume that the su() system utility is located in the /bin directory.
The start procedures in this section require you to update key system files. If errors are made, the system may no longer boot correctly, so the system administration should make these modifications.
You can use the logger() system command to store error messages displayed during an automatic start. For this to operate correctly, the syslogd() system daemon must be running on your system. The system administrator can identify the specific Transfer CFT messages in the system log files at the:
l Error level and the local0 facility for error messages
l Information level and the local0 facility for a correct start
Define the Transfer CFT service
Use a standard editor, vi for example, to create a new file called /etc/rc2.d/S99cft.
Add the appropriate operating system start shell script to this file. The following shell script provides a basic example:
#!bin/sh
# Starting Transfer CFT
if [ -f /home/cft/Axway/Transfer_CFT/runtime/profile]
then
/bin/su - mycft -c ’. Axway/Transfer_CFT/runtime/profile; cft start –batch’
fi
Define the Transfer CFT Copilot service
Use a standard editor, vi for example, to create a new file called /etc/rc2.d/S99cftcopilot.
Add the appropriate operating system start shell script to this file. The following shell script provides a basic example:
#!bin/sh
# Starting Transfer CFT Copilot
if [ -f /home/cft/Axway/Transfer_CFT/runtime/profile]
then
/bin/su - mycft -c ’. Axway/Transfer_CFT/runtime/profile; copstart’
fi
Transfer CFT 3.3.2 Installation Guide 136
7 Unix operations
Configure systemd servicesThis section describes the steps you must perform to start and stop, or update, Transfer CFT from Central Governance with Linux systemd services defined.
Note To perform the authorization procedures described in this page, you may want to refer to the sudoers documentation that corresponds with your Linux operating system.
Start the service using Central Governance or CopilotPerform the following steps to configure the Transfer CFT systemd service to start via Central Governance or Copilot, where:
l The Transfer CFT systemd service is called: cft
l The command to start this service is: sudo systemctl start cft
1. Authorize the Transfer CFT user to start the service without requiring a password. On Ubuntu/Debian, use the visudo command to add a file called cft to /etc/sudoers.d/:
sudo visudo -f /etc/sudoers.d/cft
Then add the following line:
<USERNAME> ALL=NOPASSWD:/bin/systemctl start cft
2. Create a script in the $CFTDIRRUNTIME/conf directory, for example called copcftstart, as follows:
#!/bin/sh
sudo systemctl start cft
rm $0
3. Set the UCONF copilot.misc.cftstart parameter to conf/copcftstart.
uconfset id=copilot.misc.cftstart, value=conf/copcftstart
Update using Central Governance with systemd services definedConfigure support for the systemd service to apply updates via Central Governance, where:
l The systemd service created for Transfer CFT is called: cft
l The systemd service created for Copilot is called: cftcopilot
Transfer CFT 3.3.2 Installation Guide 137
7 Unix operations
1. Authorize the user that operates Transfer CFT to start and stop both services without requiring a password.
On Ubuntu/Debian, use the visudo command to add a file called cft to /etc/sudoers.d/:
sudo visudo -f /etc/sudoers.d/cft
Add the following lines:
<USERNAME> ALL=NOPASSWD:/bin/systemctl start cft
<USERNAME> ALL=NOPASSWD:/bin/systemctl stop cft
<USERNAME> ALL=NOPASSWD:/bin/systemctl start cftcopilot
<USERNAME> ALL=NOPASSWD:/bin/systemctl stop cftcopilot
2. Create a script in the $CFTDIRRUNTIME/conf directory for each command as follows:
a. Define a copcftstart script that starts the Transfer CFT service:
#!/bin/sh
sudo systemctl start cft
rm $0
b. Define a copcftstop script that stops the Transfer CFT service:
#!/bin/sh
sudo systemctl stop cft
rm $0
c. Define a copcopilotstart script that starts the Copilot service:
#!/bin/sh
sudo systemctl start cftcopilot
rm $0
d. Define a copcopilotstop script that stops the Copilot service:
#!/bin/sh
sudo systemctl stop cftcopilot
rm $0
3. Set the following UCONF parameters, which reference the scripts to start and stop both services.
uconfset id=copilot.misc.cftstart, value=conf/copcftstart
uconfset id=copilot.misc.cftstop, value=conf/copcftstop
uconfset id=copilot.misc.copstart, value=conf/copcopilotstart
uconfset id=copilot.misc.copstop, value=conf/copcopilotstop
Transfer CFT 3.3.2 Installation Guide 138
7 Unix operations
Running CFTUTILCFTUTIL is a command line mode user interface used to create the Transfer CFT working environment manually and configure the product. It allows you to create or delete a parameter, partner, catalog, log and accounting files.
The following operations can only be carried out when Transfer CFT is shut down.
l Modify or add certain parameters
l View the parameter, partner, catalog, log and accounting files
l Send commands to the monitor
Start CFTUTILCFTUTIL is started up by entering CFTUTIL directly from the Transfer CFT program directory or from any other directory if the PATH environment variable includes the path pointing to the Transfer CFT programs.
CFTUTIL can also be activated in a shell procedure.
Line mode inputCFTUTIL accepts line mode commands. The CFT > prompt enables you to enter any commands online and validate them by pressing ENTER.
To exit CFTUTIL, enter the /end command.
Example
% CFTUTIL
CFT/V2/UAIX
Release 2.4.0 2006/12/01
(C) Copyright Axway 2000-2006
CFT> send
part=headoffice,idf=txt,fname=/home/lisa/report.txt
CFTU94I SEND part =HEADOFFICE,idf=TX _ Correct
CFT> /end
%
Run-time parametersCFTUTIL can also accept commands passed either individually as parameters or in a command file:
l Command passed as a parameter: The command line is passed as a CFTUTIL parameter using the following syntax:
CFTUTIL command parameter=value, parameter=value,...
Transfer CFT 3.3.2 Installation Guide 139
7 Unix operations
Example
CFTUTIL listcat part=headoffice, direct=send
This command displays a table of scheduled (or performed) transfers to the headoffice partner
l File passed as a parameter
The following command runs the CFTUTIL utility, which reads the commands to be executed in the scen.cft file and displays the results on the screen:
CFTUTIL @scen.cft
Declaring additional usersIf Transfer CFT is to be run by users other than the holder of the account from which Transfer CFT was installed, these users must be added to the environment.
In all subsequent definitions, it is assumed that Transfer CFT is installed, by default, in the cft subdirectory of the user root directory ($HOME).
If your installation differs, you must modify the definitions provided.
Extending the command path (PATH)To use a Transfer CFT installed in another account, the paths pointing to the Transfer CFT <installdir>/bin/, <installdir>/bin/, and <installdir>/runtime/src/exit/ command directories must appear in the PATH environment variable.
The actions required depend on the type of shell used. The following examples show how to add the <installdir>/runtime/src/exit/ directory to the path list:
If the user shell is csh (C shell), add the following command to the ~/.cshrc or ~/.login file:set path=($path ~account_cft/cft/bin)
If the user shell is sh (BOURNE shell) or ksh (KORN shell), add the following command to the $HOME/.profile file:
PATH=$PATH:root/cft_account/cft/bin; export PATH
where:
l root is the path pointing to the user directories (usually /home)
l cft_account is the name of the Transfer CFT installation account
For example, if Transfer CFT is installed in the cft subdirectory of the /home/transfer account, enter the following commands:
l For csh:set path=($path ~transfer/cft/bin)
l For sh or ksh:
PATH=$PATH:/home/transfer/cft/bin; export PATH
Transfer CFT 3.3.2 Installation Guide 140
7 Unix operations
Transfer CFT file access environmentTo access the Transfer CFT configuration files installed in another account, set the following environment variables defining the paths pointing to the Transfer CFT files and directories.
Environment variables used by Transfer CFT
The table below lists alphabetically all the environment variables used by Transfer CFT UNIX.
To simplify the descriptions, the variable name from this list will be used in the remainder of this guide to refer to the environment variables (for example, the assertion file to which CFTCATA points is equivalent to the file, the name of which is declared in the CFTCATA environment variable).
Path Pointing to the Files
Environment variable
Default definition
CFTDIRINSTALL Top of the Transfer CFT installation directory structure
CFTDIRRUNTIME Runtime directory
CFTUCONF UCONF file
CFTDIRDAT Data directory
CFTDIRINS Conf directory
CFTDIRLOG Log directory
CFTDIRPUB Pub directory
CFTDIRSEC Security directory
CFTDIREXEC Exec directory
CFTPKIDIR Directory containing the security information
CFTPKIDIR Exit directory
CFTDIRAPI Api directory
CFTHICNF Security system initialization file
CFTDSPCNF Display configuration file
CFTKEY License key file
CFTACNT Accounting file
CFTACNTA Alternate accounting file
CFTCATA Catalog file
CFTTCOM Communication file
CFTLOG Log file
CFTLOGA Alternate log file
CFTPARM Parameter file
CFTPART Partner file
CFTPKU PKI file
Transfer CFT 3.3.2 Installation Guide 141
7 Unix operations
Environment variable
Default definition
CFTHINI Security system implementation file
CFTHPARM Security system implementation parameter file
Setting the environment variables
In BOURNE shell (sh) or KORN shell (ksh), depending on your operating requirements, you must create the following commands in a file with the same strategy as the $CFTDIRUNTIME/profile file created by default during the installation procedure or add them to the $HOME/.profile file:
CFTDIRINSTALL=<path pointing to Transfer CFT installation directory>
CFTDIRRUNTIME=<path pointing to Transfer CFT runtime directory>
CFTUCONF=$CFTDIRRUNTIME/data/cftuconf.dat
. $CFTDIRINSTALL/distrib/dat/profile.inc
# Set Directories for user Convenience
_EXPORT CFTDIRDAT $CFTDIRRUNTIME/data
_EXPORT CFTDIRINS $CFTDIRRUNTIME/conf
_EXPORT CFTDIRLOG $CFTDIRRUNTIME/log
_EXPORT CFTDIRPUB $CFTDIRRUNTIME/pub
_EXPORT CFTDIRSEC $CFTDIRINSTALL/distrib/am
_EXPORT CFTDIREXEC $CFTDIRRUNTIME/exec
_EXPORT CFTPKIDIR $CFTDIRRUNTIME/conf/pki
_EXPORT CFTDIREXIT $CFTDIRRUNTIME/src/exit
_EXPORT CFTDIRAPI $CFTDIRRUNTIME/src/capi
# Set CFT Logical Names From Uconf (For information Only)
# CFTACNT ̀ cftuconf cft.cftaccnt.fname` # Accounting File
# CFTACNTA ̀ cftuconf cft.cftaccnt.afname` # Alternate Accounting File
# CFTCATA ̀ cftuconf cft.cftcat.fname` # Catalog Database
# CFTCOM ̀ cftuconf cft.cftcom.fname` # Communication Media File
# CFTLOG ̀ cftuconf cft.cftlog.fname` # Log File
# CFTLOGA ̀ cftuconf cft.cftlog.afname` # Alternate Log File
# CFTPARM ̀ cftuconf cft.cftparm.fname` # Parameter Database
# CFTPART ̀ cftuconf cft.cftparm.partfname` # Partners Database
Transfer CFT 3.3.2 Installation Guide 142
7 Unix operations
# CFTPKU ̀ cftuconf cft.cftparm.pkifname` # PKI Database
# CFTHINI ̀ cftuconf cft.cftparm.habfname` # Access Management Control File
# CFTHPARM ̀ cftuconf cft.cftparm.secparm` # Access Management Database
# Helper Environment Variables
_EXPORT CFTHICNF $CFTDIRRUNTIME/conf/default.sei
_EXPORT CFTDSPCNF $CFTDIRRUNTIME/conf/dspcnf.xml
_EXPORT CFTKEY $CFTDIRRUNTIME/conf/cft.key
_EXPORT CFTCONF $CFTDIRRUNTIME/conf/cft.conf
PATH=$PATH:$CFTDIRINSTALL/bin:$CFTDIREXIT:$CFTDIRAPI
export PATH
In C shell (csh), add the following commands to the ~/.cshrc or ~/.login file, with the following format:
setenv <variable> <descriptor>
For example, for the CFTCATA variable, you get:
setenv CFTCATA $CFTDIRRUNTIME/data/cft_cata
Privileges and rightsAll system users, irrespective of their user identifiers (uid) and group identifiers (gid), can theoretically communicate with another Transfer CFT started by a different user.
The only constraint is the rights that they have when accessing Transfer CFT configuration files. The minimum requirement is:
l Write access rights for the communication file to which the CFTTCOM environment variable points
l Read access rights for all files to which the other Transfer CFT environment variables point
l Read access rights for all Transfer CFT programs
l Read and execute access rights for all procedures written in a shell
Connecting to the Copilot server - UNIXBefore you can start Transfer CFT from the Transfer CFT UI server, the Copilot server must be started. Additionally, you require rights to log on to this server.
Transfer CFT 3.3.2 Installation Guide 143
7 Unix operations
Define rights before logging on the Transfer CFT UI server
copilot.misc.createprocessasuser
value =
With PassPort AM
Without PassPort AM
yesRoot privileges are required for CFTSU.
With PassPort AMCheck user method: operating system login Create Process: Unix User In this case, the system user must exist in PassPort AM for security rights.
yesRoot privileges are required for CFTSU.
No PassPort AMCheck user method: operating system loginCreate Process: Unix user
no (Unix default) With PassPort AMCheck user method: AM loginCreate Process: Transfer CFT UI user (Copilot)In this case, users must be defined in PassPort AM for login and security rights.
no (Unix default) No PassPort AMUsers must be created in the local Transfer CFT internal datafile (xfbadmusr)
Transfer CFT 3.3.2 Installation Guide 144
7 Unix operations
Using system users UNIXThis section describes UNIX specific tasks to perform to enable system user authentication and file system rights.
l Enable the system as user authentication on page 145
l Enable the file user rights (USERCTRL) on page 146
o Automatically start the CFTSU process on page 146
o Manually start the CFTSUD process on page 147
Enable the system as user authentication This section describes the copilot.misc.createprocessasuser parameter, which by default is set to NO for Unix systems. This means that actions made on the configuration are done with the user that started the Copilot server.
Note Once you perform all of the following steps once, there is no need to repeat these steps (they are automatic) when applying a Transfer CFT update.
To control user authentication by the system:
1. Enable the UCONF copilot.misc.createprocessasuser parameter:
CFTUTIL uconfset id=copilot.misc.createprocessasuser, value=YES
2. Log on as root.
3. Execute the profile.
4. Copy the cftsu executable to the following directory, where you must first create the cft sub-folder:
cp $CFTDIRINSTALL/bin/cftsu /opt/cft/cftsu
The destination directory, for example /opt/cft/, must be outside of the $CFTDIRINSTALL directory to allow automatic updating when apply a SP or product update.
5. Execute the commands:
chown root:root /opt/cft/cftsu
chmod u+s /opt/cft/cftsu
6. Set the copilot.unix.cftsu.fname parameter to /opt/cft/cftsu, for example:
CFTUTIL uconfset id=copilot.unix.cftsu.fname, value=/opt/cft/cftsu
7. Copy the cftsu_setup executable to the runtime_dir/bin directory:
cp $CFTDIRINSTALL/bin/cftsu_setup
$CFTDIRRUNTIME/bin/cftsu_setup
8. Execute the commands:
chown root:root $CFTDIRRUNTIME/bin/cftsu_setup
chmod u+s $CFTDIRRUNTIME/bin/cftsu_setup
Transfer CFT 3.3.2 Installation Guide 145
7 Unix operations
Enable the file user rights (USERCTRL)To enable file system rights in Unix, configure one of the following two scenarios to execute using the either the CFTSU or the CFTSUD process.
Automatically start the CFTSU processPerform the following steps so that when Transfer CFT starts the CFTSU process is automatically started.
1. Set the CFTPARM USERCTRL option to YES to enable.
2. Check that the UCONF cft.unix.cftsu.isservice parameter is set to NO (default).
3. Log on as root.
4. Go to the Transfer CFT runtime and execute the profile.
5. Copy the CFTSU executable to a directory that is outside of the $CFTDIRINSTALL directory, for example /opt/cft/:
cp $CFTDIRINSTALL/bin/CFTSU /opt/cft/CFTSU
Ensure that the destination directory is outside of the $CFTDIRINSTALL directory to allow automatic updating when you apply a Transfer CFT service pack or update.
6. Set the UCONF cft.unix.cftsu.fname parameter to the directory used above, for example /opt/cft/CFTSU.
CFTUTIL uconfset id=cft.unix.cftsu.fname,value=/opt/cft/CFTSU
7. Execute the commands:
chown root:root /opt/cft/CFTSU
chmod u+s /opt/cft/CFTSU
8. Copy the cftsu_setup executable to the $CFTDIRRUNTIME/bin directory:
cp $CFTDIRINSTALL/bin/cftsu_setup
$CFTDIRRUNTIME/bin/cftsu_setup
9. Execute the commands:
chown root:root $CFTDIRRUNTIME/bin/cftsu_setup
chmod u+s $CFTDIRRUNTIME/bin/cftsu_setup
Note After starting Transfer CFT, with a user other than root, the message CFTI34I PID=13653 /opt/cft/CFTSU Task started successfully (MQID=None)
confirms that the CFTSU steps above were successful.
CFTSU procedures for updates and upgradesYou do not need to repeat the Automatically start CFTSU process steps above when applying a Transfer CFT update after having performed this step at least once previously.
Transfer CFT 3.3.2 Installation Guide 146
7 Unix operations
However, if you execute a version upgrade:
l If you were using the CFTSU in the $CFTDIRINSTALL/bin directory, change to use the owner who installed Transfer CFT.
l Move the CFTSU to a directory outside of the $CFTDIRINSTALL/bin directory.
l Apply the upgrade.
l Execute the Start CFTSU process steps above.
Manually start the CFTSUD processIn this scenario, the root user must manually start the CFTSUD process as a service before starting Transfer CFT.
1. Set the CFTPARM USERCTRL option to YES (enabled).
2. Before starting Transfer CFT, set the uconf parameter cft.unix.cftsu.isservice to yes.
3. Set the uconf parameter to cft.unix.cftsu.afunix=$(cft.runtime_dir)/run/SCFTSU.
CFTSUD rights
Give special rights to the CFTSUD executable as follows:
1. Log on as root.
2. Execute following command:
chown root:root $CFTDIRINSTALL/bin/CFTSUD
Start CFTSUD
The root user now starts the CFTSUD process and sets the AF_UNIX file owner, which you defined in cft.unix.cftsu.afunix. This results in Transfer CFT connecting via the CFTSUD process when started.
1. Log on as root.
2. Go to $CFTDIRRUNTIME directory.
3. Execute the Transfer CFT profile:
. ./profile
4. Start CFTSUD:
CFTSUD
5. Set the AF_UNIX file owner as the user that starts Transfer CFT:
chown <cftuser>:<cftuser> <afunix_file>
Transfer CFT 3.3.2 Installation Guide 147
7 Unix operations
Switching procedure l About the switching procedure
l Switching log files
l Switching accounting files
About the switching procedureTransfer CFT maintains activity traces in primary and alternate files:
l Transfer events are stored in two log files, to which the CFTLOG and CFTLOGA environment variables point respectively
l Accounting data concerning successful transfers is stored in two accounting files, to which the CFTACNT and CFTACNTA environment variables point respectively
The switching principle is described the housekeeping topic in the Transfer CFT User Guide.
Switching between the primary and alternate files is configured by the operator when Transfer CFT is configured. It requires the following definitions:
l The time at which switching is to take place each dayThis switching time is entered using the SWITCH command
l The switching procedure, using the EXEC command; this procedure, written in the shell, controls the switching operation
The SWITCH and EXEC commands must be added as follows:
l To switch log files, the following declaration is used in the CFTLOG section:
CFTLOG ID = log0,
FNAME = '_CFTLOG', /* Log file */
AFNAME = '_CFTLOGA', /* Alternate log file */
SWITCH = 2359, /* Switching time */
EXEC = 'switch.cmd' /* Switching procedure */
l To switch accounting files, the following declaration is used in the CFTACNT section:
CFTACCNT ID = acct0,
FNAME = '_CFTACNT', /* Accounting file */
AFNAME = '_CFTACNTA', /* Alternate accounting file */
SWITCH = 2359, /* Switching time */
Exec = 'switch.cmd',/* Switching procedure */
Note After the switching procedure has completed, the old files used must be purged so that they can be reused by Transfer CFT for the next switch.
If this is not done, Transfer CFT will freeze the next time it is started.
Transfer CFT 3.3.2 Installation Guide 148
7 Unix operations
Switching log procedureIn the log file, Transfer CFT begins working on the file that CFTLOG points to. After the first switch, Transfer CFT uses the file that CFTLOGA points to. At the next switch, it returns to the file to which CFTLOG points and so on, using in turn the files to which CFTLOG and CFTLOGA point.
With this method, the current and previous, from the day before, log files are maintained.
Although this is an adequate solution for straightforward operations, you may wish to have a slightly longer archiving period.
The example below describes a simplified procedure that maintains a history over four days rather than two. This switching procedure, switch.cmd, is located in the <installdir>/runtime/conf/ directory and is used in the cft-tcp.conf sample configuration.
Example: switching log files
This procedure is an example. It does not, for example, take into account the various error conditions. Its contents are as follows:
#!/bin/sh
#
# Sample LOG file switching procedure
#
filename=`cft2unix &flog`
mv ${filename} ${filename}_sav
CFTUTIL CFTFILE type=log,fname=$filename
rm $0
The effects of each line in the procedure are as follows:
l #!/bin/sh
Use of the BOURNE shell is systematically forced; even if it is not essential for this example, it is a good safety measure
l filename=`cft2unix &FLOG`
l The Transfer CFT FLOG symbolic variable is used to retrieve the name of the log file to which the CFTLOG environment variable points (Transfer CFT symbolic variables are described in the Transfer CFT Concepts guide)
l The cft2unix utility is provided in the <installdir>/bin directory. It receives the physical name of a file if &flog contains a Transfer CFT logical name. Otherwise, it returns the name passed as a parameter
Example: the cft2unix log command returns log whereas cft2unix_CFTLOG returns the value of the CFTLOG environment variable.
The name of the log file is then stored in the filename variable (cft_log for example)
Transfer CFT 3.3.2 Installation Guide 149
7 Unix operations
l mv ${filename} ${filename}_sav
l The log file to which filename points is copied to a new file and given the _sav extension (cft_log becomes cft_log_sav for example)
l CFTUTIL CFTFILE TYPE=LOG, FNAME=$filename
l The initial log file is recreated. Do not forget that the log file concerned must be empty, so that Transfer CFT can use it for switching
l rm $0
The temporary file is deleted (see the section Transfer CFT and Temporary Files).
Switching accounting filesA simplified version of the previous procedure for switching the accounting file with the same backup properties is described below. This switching procedure, switchacnt.cmd, is located in the <installdir>/runtime/conf/ directory and is used in the cft-tcp.conf sample configuration provided.
Example: switching accounting files
#!/bin/sh
#
# Sample accounting file switching procedure
#
filename=`cft2unix &FACCNT`
mv ${filename} ${filename}_sav
CFTUTIL CFTFILE TYPE=ACCNT, FNAME=$filename
rm $0
This procedure is an example intended to illustrate the concept. It does not take into account possible error conditions.
Processing accounting filesTransfer CFT maintains accounting data on successful transfers in two accounting files. The primary and alternate files are managed in turn and are pointed to by the CFTACNT and CFTACNTA environment variables, respectively.
This topic provides an example of the accounting file, and how to test that the accounting configuration is correct.
The general principles of accounting files are described in Defining the recording mode.
Unlike log files, the ASCII contents of which can be viewed directly using an editor or other standard tool, accounting files are binary-coded. A specific tool is required to process this information depending, on the criteria applying in each work situation.
Transfer CFT 3.3.2 Installation Guide 150
7 Unix operations
The programming example provided below should clarify this aspect. The program operates in a similar way to the catalog display commands, in that it scans an accounting file and displays all the fields stored for each record.
Note The data stored in the accounting files is likely to change over time in terms of volume or value. You are therefore advised to recompile any program that you may develop from the information provided in these files each time Transfer CFT is updated.
Although this example is part of the standard package, it is only loaded on to your system if you request the Programming interface and EXITs installation option.
Sample file componentsThe <installdir>/runtime/src/exit subdirectory contains:
l A sample source module, called exacct.c, with its associated include file (exacct.h)
l The mk_exacct compilation procedure, which uses the exacct.c sample source module to generate the EXACCT executable file; this file is automatically stored in the <installdir>/bin/ subdirectory
To generate the EXACCT sample file, proceed as follows:
1. Access the <installdir>/runtime/src/exit/ directory.
2. Enter the command:
make -f mk_exacct
The sample file provided uses the Full ANSI C syntax. If your C compiler does not use this mode by default, set the appropriate option.
On some systems (HPUX for example), a compilation error may arise because theuchar_t type is undefined. If this occurs, rerun the make command with theadditional parameter CFLAGS=-DACCT_UCHAR, in other words:
make -f mk_exacct CFLAGS=-DACCT_UCHAR
Testing the accounting file configurationThis test can only be run if you have already made successful transfers with Transfer CFT from one of the test configurations provided (cft-tcp.conf or cft-coms.conf).
Proceed as follows:
1. Access the <installdir>/runtime/log/ directory.
2. Using the ls -l command applied to this directory, select the file to be tested from the two accounting files (by default the cft_acnt file or the cft_acnta alternate file). The alternate file is used in the example.
3. Run the EXACCT program with the name of the accounting file as a parameter:
EXACCT cft_acnta
4. Check that the various fields of your transfers are displayed.
Transfer CFT 3.3.2 Installation Guide 151
7 Unix operations
Suffix managementBy default, during file send or receive operations, Transfer CFT uses the file type, FTYPE, to determine the action to be taken. However, Transfer CFT also features a mechanism called suffix management which enables Transfer CFT to determine the type of file processed from the file name. This topic describes:
l Defining suffixes
o Enabling suffix management
l Separating file name extensions
Defining suffixesFor Transfer CFT a suffix is the rightmost part of the file name, and may have up to eight characters.
To be recognized by Transfer CFT, a suffix must be declared in the suffixes.def file located in the directory to which the CFTDIRDAT environment variable points, usually the <installdir>/runtime/data/ directory.
The suffix definition file is a text file that the user creates using a text editor, vi for example. Each suffix definition must be in the form: <suffix>=<FTYPE>
Where:
l The length of the suffix is less than or equal to eight characters
l FTYPE is one of the file types recognized by Transfer CFT
Furthermore, the lines making up the suffixes.def file must comply with the following rules:
l There can be only one suffix definition per line
l Suffixes can be defined with wildcard characters, which define either any character (?) or any character string (*)
l The suffix definitions are case-sensitive but the types are not. Type t is, therefore, identical to type T, but the suffix .txt is different from the suffix .TXT
l Empty lines and lines containing only spaces are ignored
l Comments can be inserted in this file using the # characterAny text situated between a # character and the end of the line will be considered to be a comment
Sample suffix definition file:
## Sample suffix definition file#.doc=O # MS-DOS text file (param.doc for example).txt=T # UNIX text file(cft.txt for example)*.bin=B # Binary file (fil.bin for example)*.dat?=B # Binary file (john.dat0,fred.data for example)
Transfer CFT 3.3.2 Installation Guide 152
7 Unix operations
# ...
Enabling suffix managementSuffix management is enabled by setting the FTYPE field to a space in the CFTSEND or CFTRECV sections. In the Transfer CFT syntax, this space must be placed between single quotes.
Example
CFTSEND ID = DAT,FTYPE = ' ',MODE = REPLACE
Separating file name extensionsTransfer CFT provides a parameter option that allows the user to the separate the file name from the file extension, mimicking the Transfer CFT Windows functionality.
In Transfer CFT the name of a file is referred to as ROOT or FROOT, and the file extension (suffix) is FSUF or SUF. So for example, if you have a file called sample.txt and in Transfer CFT you define FROOT=sample.txt, then in standard functioning:
l In Unix the FSUF is empty
To enable the option to separate the file name and extension in Unix, set the following UCONF value to yes:
cft.unix.parse_file_name_suffix=yes
For more information on unified configuration parameters, see UCONF: Unix-specific parameters.
Transfer CFT temporary filesDepending on the processing involved, Transfer CFT creates various temporary files in the /tmp directory. This topic describes temporary files, how to delete them, and provides an example.
Temporary files
Transfer CFT temporary filesThere are four types of temporary files corresponding to different types of actions:
l /tmp/cftlo* files are produced during the log switching procedure
l /tmp/cftcn* files are produced when the accounting feature is enabled
l /tmp/cftsu* files are produced when end of transfer procedures are run
l /tmp/cftsu*.err files correspond to the results of commands in the cftsu* files
Transfer CFT 3.3.2 Installation Guide 153
7 Unix operations
Deleting temporary filesTransfer CFT cannot delete temporary files automatically. It does not know exactly when the end of the user script is reached.
To avoid saturating the /tmp directory, you should end any shell procedure with the rm $0 command.
Note If this command is omitted, the /tmp partition rapidly becomes full and the end of transfer procedures will fail.
This command deletes the procedure that runs it and is applicable to cftlo*, cftfcn* and cftsu* files.
Additionally, the cftsu*.err files associated with cftsu* files should be deleted. However, to avoid losing any errors that may be logged in this file, it is best to check that the file is empty before deleting it.
For example, write:
if test -s $0.err
thenecho $0.err contains data to be consulted
elserm $0.errfi
TMPDIR environment variableYou can use the environment variable TMPDIR=<path> to define a temporary directory in Unix and POSIX. If you define TMPDIR, the temporary file goes in this directory. If you do not define TMPDIR, Transfer CFT uses the default directory (/tmp).
Example
export TMPDIR=/home/Desktop/tmpdir/
Sample procedureThe contents of the recvm.cmd file stored in <installdir>/runtime/conf/ are shown below. The recvm.cmd file is a sample procedure executed after receiving a message.
This procedure must first be declared in the CFTPARM section of your configuration file, in the EXECRM field, so that it can be executed.
Example:
EXECRM = '/home/transfer/cft/<installdir>/runtime/conf//recvm.cmd'
The contents of the recv.cmd file are as follows:
echo "MESSAGE RECEIVED" /* display of the message received */
Transfer CFT 3.3.2 Installation Guide 154
7 Unix operations
echo "** &msg **" /* by CFT using the &msg symbolic */
/* variable that contains the */
/* message text */
rm $0 /* deleting the /tmp/cftsu* */
/* temporary file */
if test -s $0.err
thenecho $0.err contains data to be consulted
elserm $0.errfi
Transfer CFT identificationSome clients package Transfer CFT/UNIX to meet the special requirements of their company. This specific package can apply to both the product in its ready-to-install state, as delivered by Axway, and the product specifically preconfigured for the company.
To make it easier to identify this type of product, a specific directory is available on the delivery medium and product following installation. This directory is called .info (the dot must be included before the name).
This .info directory is located:
l For the installable product, on the same level as the other product files to install
l For the installed product, in the subdirectory in which Transfer CFT/V2/UNIX was generated, in the examples provided in this guide, this is the cft directory
This directory comprises a series of subdirectories ending with an empty file. These various levels provide the information below in the following order:
l Transfer CFT release, cft240 for example
l Product generation date, 20060307 for example
l Operating system, AIX for example
l Operating system release, for example, for AIX: 43
l If necessary, the hardware manufacturer, for example, for AIX: IBM
Taking the examples above, the complete directory structure is as follows:
.info/cft240/20060307/AIX/43/IBM
Note This directory and the information it contains are also used by Transfer CFT. As some utilities are very similar from one product release to another, the release information is retrieved to fine-tune the way in which the utilities behave.
Transfer CFT 3.3.2 Installation Guide 155
7 Unix operations
Client/server variable additionsTo allow recent clients to dialog with older servers, several additions have been made to the environment for Transfer CFT releases on UNIX systems. This topic describes the additional environmental variables for the Client/server model.
These additions are mainly used when creating a:
l cftinq.cfg configuration file
l CFTDIRINQ environment variable
Client/server environmental variables
cftinq.cfg configuration fileThe cftinq.cfg file is found in the <installdir>/runtime/data/ subdirectory. When Transfer CFT is running normally, not in client/server mode, the appropriate values for your local Transfer CFT are automatically set in this file.
CFTDIRINQ environment variableWhen Transfer CFT is installed, an environment variable called CFTDIRINQ is automatically set. By default, not in client/server mode, its content points to the Transfer CFT <installdir>/runtime/data/ subdirectory containing the cftinq.cfg file.
Client/server modeTo enable a client to dialog with a server, the CFTDIRINQ variable must contain the path pointing to the cftinq.cfg file of the remote server, as provided by the remote site administrator.
Transfer CFT user interface Transfer CFT user interface, Copilot, is a screen-based user interface enabling you to prepare and monitor most aspects of Transfer CFT operations.
[FOR DETAILS: User interfaces: Start here]
UNIX-specific unified configuration optionsThis topic describes the unified configuration values to define for the following Unix options in Transfer CFT:
l Command line history: enable readline
l System user: define CFTSU
Transfer CFT 3.3.2 Installation Guide 156
7 Unix operations
l Separating filenames from the file extension
l General Unix-specific parameters
Command line history (readline)
Parameter Default Description
cft.unix.readline.enable YES | NO Enable readline history for CFTUTIL PKIUTIL and SECUTIL.
cft.unix.readline.history_fname
$(HOME)/.cft_history
Readline history file.
cft.unix.readline.history_size
1000 Readline history size.
System user
Parameter Description
cft.unix.cftsu.afunix Defines the address family file for inter-process communications.
cft.unix.cftsu.isservice Defines the use of CFTSU as a service.
cft.unix.cftsu.fname Specify the absolute path name to the CFTSU to execute when the user control is enabled, to enable upgrading without being the system administrator.See Unix: Using system users.
Transfer CFT 3.3.2 Installation Guide 157
7 Unix operations
Separating filename and extension
Parameter Default Description
cft.unix.parse_file_name_suffix
No Use this setting for a Transfer CFT running in Unix to separate the extension from the name of the file, as is done in Windows.Possible values:
l Yes: Enables Unix to mimic Windows functioning so that the name of the file and the type of extension are presented separately
l No: Disables the feature to have normal Unix file functioning with no extension type displayed
See Suffix management.
UNIX parameters
ID Default Former value
cft.unix.active_trans (int) 256 active_trans (cftstart)
cft.unix.start_timeout (int) 30
cft.unix.stop_timeout (int) 30
cft.unix.passwd_fname (fname) $(cft.runtime_dir)/conf/passwd
cft.unix.passwd_temp (fname) $(cft.runtime_dir)/conf/passwdXXXXXX
cft.unix.group_fname (fname) $(cft.runtime_dir)/conf/group
cft.unix.group_temp (fname) $(cft.runtime_dir)/conf/groupXXXXXX
cft.unix.cfttrk_out_fname (fname) $(cft.runtime_dir)/run/cfttrk.out
cft.unix.pid_fname (fname) $(cft.runtime_dir)/run/cft.pid
cft.unix.ipc_fname (fname) $(cft.runtime_dir)/run/cft.ipc
copilot.unix.unix_socket_fname
(fname) $(cft.runtime_dir)/run/S_COPSMNGFW
copilot.unix.pid_fname (fname) $(cft.runtime_dir)/run/copilot.pid CFTCOPILOTPID
Transfer CFT 3.3.2 Installation Guide 158
7 Unix operations
Define additional environment variables Unix
When loading the Transfer CFT profile, files that are stored in the profile.d directory are also executed, and all of the defined environment variables are then available in the current environment. This enables you to use these variables in the Transfer CFT configuration or processing scripts.
Procedure 1. Create a new file in the $CFTDIRRUNTIME/profile.d directory, and add your customized
variables as follows. For example:
_EXPORT MYVARIABLE01 TheVariableValue01
_EXPORT MYVARIABLE02 TheVariableValue02
2. Execute the profile command.
Transfer CFT 3.3.2 Installation Guide 159
7 Unix operations
About Transfer CFT utilitiesThis section describes Transfer CFT Unix utilities. These utilities are divided into the following groups:
l Management utilities
l Control utilities
l System utilities
Note In this section, the term Transfer CFT designates the Transfer CFT software package on UNIX platforms.
This topic describes the Transfer CFT utilities that you find in the cft/<installdir>/bin/ sub-directory after completing installation.
OverviewThe Transfer CFT utilities described here, do not replace the basic commands described elsewhere in this document. Their purpose is to simplify common tasks performed with Transfer CFT.
For parameters details, refer to the corresponding command in the Transfer CFT Command Guide > Parameters index.
Transfer CFT utilities in UNIXThe available utilities are listed below in alphabetical order.
Utility Definition
atoe ISO 8859-1 ASCII to EBCDIC conversion table.
cft2unix Utility setting Transfer CFT environment variables.
cftalog Direct display of the secondary (alternate) Transfer CFT log file.
cftcata Verbose display of the Transfer CFT catalog file.
cftcatab Brief display of the Transfer CFT catalog file.
cftcatal Utility migrating and/or extending the Transfer CFT catalog file.
cftdelcat Utility deleting an entry from the catalog.
cftinit General Transfer CFT initialization utility.
cftkey System data display.
Transfer CFT 3.3.2 Installation Guide 160
7 Unix operations
Utility Definition
cftlog Direct display of the Transfer CFT log file.
cftparm Direct display of the configuration parameters component.
cftpart Direct display of the configuration partners component.
cftping Transfer CFT state assessment utility.
cftstart Controlled startup of Transfer CFT.
cftstop Controlled shutdown of Transfer CFT.
cftupdate Utility updating the Transfer CFT configuration.
cftutil Simplified display of the standard CFTUTIL commands.
cftversion Utility retrieving the Transfer CFT release.
etoa EBCDIC to ISO 8859-1 ASCII conversion table.
secinit Utility initializing the Transfer CFT security environment.
secupdate Utility updating the Transfer CFT security environment.
xfbadmgrp Group management utility (all users accessing the Copilot server).
xfbadmusr Utility managing users accessing the Copilot server.
xvi Utility processing the conversion tables.
Conversion tablesBy default, Transfer CFT uses internal tables to convert ASCII characters to EBCDIC and vice versa. They are based on the ASCII character set as defined on PC/DOS systems.
If you want to perform a conversion using the ISO 8859-1 ASCII character set, run the CFTXLATE command with the following external conversion tables:
l atoe: ISO 8859-1 ASCII to EBCDIC
l etoa: EBCDIC to ISO 8859-1 ASCII
The xvi utility described in System utilities can be used to create specific conversion tables or modify existing tables.
Transfer CFT 3.3.2 Installation Guide 161
7 Unix operations
Management utilitiesThis topic describes the following management utilities:
l cftinit
l cft start
l cft stop
l cft update
l cftutil
l secinit
l secupdate
Management utilities descriptions
cftinitcftinit is a general Transfer CFT initialization utility.
Syntax
cftinit [<filename> [<filename>...]]
Standard use
cftinit is normally used with a single parameter, which is the name of the Transfer CFT configuration file.
cftinit my_config.cft
Advanced use
Several file names can be included in the command line. Normally, all Transfer CFT parameters are declared in a single file. However, for organizational reasons, you may wish to separate the configuration into several files (for example, a file describing the CFTPART cards and another file containing the CFTPARM, CFTLOG cards, and so on).
cftinit partners.cft the_rest.cft
Note
l If no file name is passed as a parameter, the program requests one or more file names
l If no name is supplied, the program stops
l When cftinit is launched, it creates the catalog and communication files. You can modify the default sizes of these files to suit your requirements by updating the uconf values for cft.cftcat.default_size and cft.cftcom.default_size (these values are expressed as a number of records).
Transfer CFT 3.3.2 Installation Guide 162
7 Unix operations
cft startThe cft start utility performs a controlled startup of Transfer CFT and its additional elements.
Syntax
cftstart [<idparm> | -batch]
Standard use
cft start is normally used without parameters. It checks the Transfer CFT environment to ensure that Transfer CFT starts up correctly. It then runs Transfer CFT, waits for the processes to start up and displays an information message with the process identifier (PID) of the CFTMAIN process.
% cft start
Starting CFT with IDPARM "IDPARM0"
Starting CFTMAIN ... started
Starting CFTTCOM .... started
Starting CFTTPRO ... started
Starting CFTLOG ... started
CFT started correctly.
CFTMAIN process ID is 23564.
%
Advanced use
If Transfer CFT is configured with advanced settings, the IDPARM field can be passed as a parameter. If no parameter is entered, IDPARM0 is used by default. If an invalid IDPARM value is entered, cftstart displays the values available in the Transfer CFT configuration.
%cftstart IDPARM1
Invalid IDPARM "IDPARM1".
Valid IDPARMs are:
CFTPARM ID = 'IDPARM0',
CFT not started.
%
Batch mode
You must only use the cftstart command with the -batch option when starting up Transfer CFT automatically at system startup. This additional option only modifies the way in which the command is displayed
The logger() system command is used to store any error messages displayed during automatic startup. Therefore, for this device to operate correctly, the syslogd() system daemon must be running on your system. The system administrator will easily identify in the system log files the specific Transfer CFT messages, which are:
l Error level and local0 facility for error messages
l Information level and local0 facility for correct startup
Transfer CFT 3.3.2 Installation Guide 163
7 Unix operations
The -batch parameter cannot be used with the IDPARM parameter.
Notes: cftstart triggers a timeout each time a process required by Transfer CFT is activated. Normally, this timeout is sufficiently long, but if the system has an excessive load or is an old system that is too slow, cftstart may generate a spurious error. If this happens, edit the cftstart shell and change the start_timeout field at the beginning of the file to a suitable value (in seconds).
When the system is delivered, cftstart does not automatically activate the additional Transfer CFT elements such as SCOPE or Copilot by default. To customize cftstart operation, refer to Using Additional Elements.
cft stopThe cft stop utility performs a controlled shutdown of Transfer CFT.
Syntax
cft stop [-kill]
Standard use
The cft stop command, used without parameters, shuts down Transfer CFT by sending the SHUT FAST=YEScommand. It then waits until the various Transfer CFT processes are stopped.
% cft stop
Waiting for CFTLOG .... stopped
Waiting for CFTTCPS ... stopped
Waiting for CFTTPRO ... stopped
Waiting for CFTTCOM ... stopped
Waiting for CFTTFIL ... stopped
Waiting for CFTMAIN ....stopped
CFT stopped correctly.
%
If cft stop detects abnormal behavior during the shutdown phase, it displays the following message:
% cft stopInvalid state of Transfer CFT.
Use Cft force-stop to force Transfer CFT to shut down.
Advanced use
In the event of a problem, the program recommends that you shut down Transfer CFT using theCft force-stopcommand.
This command then forces a Transfer CFT shutdown. It is normally successful, but depending on the state of the system, more serious malfunctions may be encountered.
If a serious malfunction occurs at Transfer CFT level, an alarm message is displayed before continuing with the housekeeping procedure, to inform you about the possible consequences of the next command.
Transfer CFT 3.3.2 Installation Guide 164
7 Unix operations
Note In the event of a serious malfunction, this command removes the message queues, shared memory segments and semaphore vectors assigned to the Transfer CFT user. This could be fatal to any other applications started up by the user and calling on the same types of resources.
% cft stopInvalid state of CFT.UseCft force-stop to force shutdown of Transfer CFT% cft stop -kill
****************** WARNING ***
***************
Using this action can seriously damage the IPC status of otherapplications running on the same login (as X server).
If you are not sure, use the ^C command and contactyour technical support.
If you want to continue, enter the word 'yes' : yes
### Process destruction ###Killing process 'CFTLOG', pid 18210Killing process 'CFTTCPS', pid 38966Killing process 'CFTTPRO', pid 38438Killing process 'CFTTCOM', pid 36388Killing process 'CFTTFIL', pid 36268
### IPC destruction ###Removing msg queue 61455Removing msg queue 57360Removing msg queue 98321Removing msg queue 90130Removing msg queue 233491Removing shared memory 69638Removing shared memory 36871Removing semaphore 49167Removing semaphore 49168CFT stopped.
%
Note
l cftstop triggers a timeout each time a process required by Transfer CFT is shut down.Normally, this timeout is sufficiently long, but if transfers are in progress or the system has an excessive load or is an old system that is too slow, cftstop may generate a spurious error. If this happens, simply edit the cftstop shell and change the stop_timeout field at the beginning of the file to a suitable value (in seconds) to correspond to the DISCTD and DISCTS fields in your configuration.
l When the system is delivered, cftstop does not automatically shut down the additional Transfer CFT elements such as SCOPE or Copilot by default.To customize cftstop operation, refer to Using Additional Elements.
Transfer CFT 3.3.2 Installation Guide 165
7 Unix operations
cftupdateThe cftupdate utility is used to update the configuration.
Syntax
cftupdate <filename> [<filename> ...]
Notes:
l You can only update the CFTPART, CFTxxx (for the networks), CFTSEND cards, and so on
l This command should be considered to be an alias of CFTUTIL @<filename> for each file name passed as a parameter in the command line
cftutilThe cftutil command submits a standard CFTUTIL instruction, but displays the results without a banner. In addition, if the command return code is non-null, a message is displayed.
Syntax
cftutil <command>
Use
% cftutil listcat type=zCFTU26E LISTCAT _ Error (TYPE Bad value for parameter)cftutil code 115%
secinitThe secinit utility is used to initialize the Transfer CFT security environment.
Syntax
secinit [<filename> [<filename>...]]
Standard use
secinit is normally used with a single parameter, which is the name of the file containing the Transfer CFT security configuration.
secinit my_config.cft
Advanced use
Several file names can be included in the command line. Normally, all Transfer CFT security parameters are declared in a single file. However, for organizational reasons, you may wish to separate the parameters into several files.
secinit start_my_config.cft the_rest.cft
Transfer CFT 3.3.2 Installation Guide 166
7 Unix operations
Note
l If no file name is passed as a parameter, the program will request one or more file names
l If no name is supplied, the program stops
l When activated, secinit creates the security database
secupdateThe secupdate utility is used to update the Transfer CFT security environment.
Syntax
secupdate <filename> [<filename> ...]
This command should be considered to be an alias of SECUTIL @<filename> for each file name passed as a parameter in the command line.
Transfer CFT control utilitiesThis topic describes the following Transfer CFT control utilities and their syntax:
l cftcata
l cftcatab
l cftcatal
l cftlog
l cftalog
l cftparm
l cftpart
l cftdelcat
l xfbadmgrp
l xfbadmusr
Control utilities descriptions
cftcatacftcata is a shortcut for the CFTUTIL LISTCAT command with the TYPE=ALL, CONTENT=DEBUG options.
Syntax
cftcata [IDT]
Transfer CFT 3.3.2 Installation Guide 167
7 Unix operations
Standard use
This command is used without parameters. cftcata displays the entire Transfer CFT catalog page by page but without a banner (debug mode).
Advanced use
This command is used with a transfer identifier (IDT) as a parameter. cftcata displays the entire contents of the Transfer CFT catalog page by page and without a banner (debug mode) for the relevant identifier.
cftcatabcftcatab is an improved shortcut for the CFTUTIL LISTCAT command with the TYPE=ALL, CONTENT=BRIEF options
Syntax
cftcatab [STATE]
Standard use
When used without parameters, cftcatab displays a condensed version of the Transfer CFT catalog page by page but without a banner (brief mode).
Advanced use
When used with a transfer state (STATE) as a parameter. cftcatab displays a simplified version of the Transfer CFT catalog page by page and without a banner (brief mode) for the selected transfer state.
cftcatalThe cftcatal utility is used in particular to dynamically increase the size of the Transfer CFT catalog file, without losing information.
Syntax
cftcatal
The cftcatal command is used to modify the size of the Transfer CFT catalog. In a multi-node environment, this action resizes all nodes.
cftlogcftlog is a shortcut to display the Transfer CFT log file page by page. The page by page display is obtained via the more utility.
Syntax
cftlog
Transfer CFT 3.3.2 Installation Guide 168
7 Unix operations
cftalogcftalog is a shortcut to display the secondary (alternate) Transfer CFT log file page by page. The page by page display is obtained via the more utility.
Syntax
cftalog
cftparmcftparm is a shortcut for the CFTUTIL LISTPARM TYPE=ALL command.
Syntax
cftparm
cftpartcftpart is an improved shortcut for the CFTUTIL LISTPART TYPE=ALL command.
Syntax
cftpart
cftdelcatcftdelcat is an improved shortcut for the CFTUTIL DELETE command.
Syntax
cftdelcat [part=PART]
Standard use
This command is used without parameters. cftdelcat deletes all entries in the Transfer CFT catalog.
cftdelcat
Advanced use
This command is used with a partner (BOSTON in the example). It deletes all Transfer CFT catalog entries for the selected partner.
cftdelcat part=BOSTON
Transfer CFT 3.3.2 Installation Guide 169
7 Unix operations
xfbadmgrpThe xfbadmgrp utility is used to create, delete, modify and check a group (of users) with access rights to the Copilot server. It can be used in interactive mode associated with a command (add, delete, and so on) or in batch mode, specifying each of the required commands (-G group –p passwd, and so on).
General command syntaxAdd a user group:
xfbadmgrp add [-G <group>] [-p <passwd>] [-g <GID>] [-u <users>]
Delete a user group:
xfbadmgrp delete [-G <group>]
Modify a user group:
xfbadmgrp modify [-G <group>] [-p <passwd>] [-g <GID>] [-u <users>]
Display information on existing groups:
xfbadmgrp print [-G <group>]
This command displays information on a given group (if the -G option is used) or on all existing groups.
Standard usexfbadmgrp add | delete | modify | print | check | help
Advanced Use
Various options can be used to make it easier to enter information or allow you to work in batch mode:
l -G <group> : ASCII name of the user group
l -p <passwd> : Password required to access this group
l -g <GID> : Numeric identifier of the group. If it is set to AUTO, the GID is generated automatically
l -u <usr1,usr2> : List of existing users, separated by a comma
xfbadmusrThe xfbadmusr utility is used to create, delete, check, and modify a user with access rights to the Copilot server. It can be used in interactive mode associated with a command (add, delete, and so on) or in batch mode, specifying each of the required commands (-G group -p passwd, and so on).
Transfer CFT 3.3.2 Installation Guide 170
7 Unix operations
General command syntax
Add a user
If the group does not exist, it is automatically created with the user login name.
xfbadmusr add [-l <login>] [-p <passwd>] [-u <UID>] [-g <GID>]
Delete a user
Users in the group file are automatically deleted from all the groups with which they are associated.
xfbadmusr delete [-l <login>]
Modify a user
If necessary, modifications are applied automatically to the group file.
xfbadmusr modify [-l <login>] [-p <passwd>] [-u <UID>] [-g <GID>]
Check a user
xfbadmusr check [-l <login] [-p passwd]
Display information on existing users
Display information on a given user (if the -l option is used) or on all existing users.
xfbadmusr print [-l <login>]:
Standard Use
xfbadmusr add | delete | modify | print | check | help
Advanced Use
You can use the following options to make it easier to enter information, or to work in batch mode:
l -l < login >: Login name
l -p < passwd >: Password
l -u < UID >: User identifier - When set to AUTO, a UID is generated automatically
l -g < GID >: Group identifier - When set to AUTO, the GID is generated automatically
System utilitiesThis topic describes the following Transfer CFT system utilities:
l cft2unix
l cftkey
Transfer CFT 3.3.2 Installation Guide 171
7 Unix operations
l cftversion
l cftping
l xvi
cft2unixThe cft2unix utility is used in a user shell to obtain the value of an environment variable or the name of a logical file used by Transfer CFT. This command is useful when switching between log and accounting files. See the section on switching procedures in the topic Configuring Transfer CFT.
Syntax
cft2unix <string>
Use
% cft2unix _CFTLOG/home/transfer/cft/<installdir>/runtime/log//cft_log%
cftkeycftkey is a small utility used only to display all information that may be requested by the Axway Technical Support Team for details about your system.
Syntax
cftkey
Use
% cftkey
Technical System Data-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-build IBMmodel A0procs 02cpuid 8828D8828D8828D8syst AIXlevel 4state 1
The example above shows the information supplied by cftkey on an AIX 4.1-based IBM system.
Note that the procs item indicates:
l The value 1+ if the number of processors cannot be determined dynamically, or
l The number of processors physically available on the system (and not the number of active processors)
Transfer CFT 3.3.2 Installation Guide 172
7 Unix operations
cftversioncftversion provides the same result as the CFTUTIL ABOUT command but without the associated banners. This is a quick method of providing the sales department with the information required, for example, to calculate the software protection key or determine the Transfer CFT technical level.
Syntax
cftversion
Use
% cftversionCFT/V2/UAIX2.4.1 2006/12/01 <- Generation dateCopyright AXWAY 2006
information:* product = CFT/V2/UAIX* version = 241* level = 1a-200-U0C* Upgrade = 1404
information: <- Information required to* model = A0 <- calculate the software* cpuid = 8828D8828D8828D8 <- protection key
ABOUT _ Correct
cftpingThe cftping utility is used to determine whether Transfer CFT is running on the user account.
Syntax
cftping [-h | -v | -i | -p]
Note The results of this command do not guarantee that Transfer CFT is 100% operational. They do indicate that the product normally generated when Transfer CFT is activated, CFTMAIN and main shared memory segment, are present on the system.
Use in a shell script
One of the advantages of cftping is that by testing the command return code, you can determine whether or not Transfer CFT is running in the operator's account. The two commands described earlier, cftstart and cftstop, use cftping.
If it is used in a shell script without any options, the program returns the following values:
l 0: Transfer CFT is not running; the environment (shared memory) is correct
l 1: Transfer CFT is running; the environment (shared memory) is consistent
Transfer CFT 3.3.2 Installation Guide 173
7 Unix operations
l 2: Transfer CFT is running but the status is inconsistent at shared memory level
l 3: Transfer CFT is not running (CFTMAIN is not present) but the status is inconsistent (at leastone of the shared memory segments exists)
l 9: procedure error
These values can easily be retrieved and processed in a shell script. For example, a script written in Korn Shell may contain the following lines:
cftpid = `cftping -p` # store CFT PIDcode = $? # cftping execution codeif [ "$code" != "0" ]thenecho "CFT is not running"else
Your error handling code....fi
Use in interactive mode
Where:
l -v: verbose mode (displays the current Transfer CFT status as alive, not running or dead)
l -i: information (provides information on the shared memory and semaphores)
l -p: PID (provides the PID of the process that created the shared memory)
Normally, the user enters the command in its simple form:
cftping -v
The three possible responses are as follows.
l If Transfer CFT is not running and the system status is consistent:
% cftping -vcft: not running
l If Transfer CFT is running (CFTMAIN present and system status consistent):
% cftping -vcft is alive
l If Transfer CFT is in inconsistent status (several types of message are possible):
% cftping -vcft: pid 26840 is dead
xviThe xvi utility is used to update a conversion table.
Syntax
xvi [-d | -a | -e | -l <file> ] <table>
Transfer CFT 3.3.2 Installation Guide 174
7 Unix operations
Standard use
xvi <table>: updates an existing, valid <table> (256 characters).
Advanced use
The following options can be used with xvi:
l -d: displays an existing, valid <table> in ASCII
l -a: creates a <table> to convert ASCII to EBCDIC; this table is identical to the one accessed via the Transfer CFT CFTXLATE command (if <table> exists, it is overwritten)
l -e: creates a <table> to convert EBCDIC to ASCII; this table is identical to the one accessed via the Transfer CFT CFTXLATE command (if <table> exists, it is overwritten)
l -l: creates a <table> from an ASCII <file>; the file generally used is the file produced after running option -d (if <table> exists, it is overwritten)
About API applicationsThis book describes one of two Transfer CFT programming interfaces, the API applications. This interface enables Transfer CFT to work in conjunction with external applications.
This book begins with this topic which introduces the two application families that can be developed using these two interfaces and the development kit contents for building APIs.
l Applications communicating with Transfer CFT to submit and monitor transfers or query the catalog, for example. See Using APIs.
l Exits enabling user programs to take control during a send operation. See Managing exits.
Transfer CFT only provides a programming interface in C. This programming interface can only be used if the development kit is installed on your system, C compiler and associated tools.
This book is comprised of the following topics which describe how to create an API application.
Topic Details
Creating an API application
Describes the procedure to create an API application in Transfer CFT UNIX.
Creating an exit file Describes how to create an exit file for Transfer CFT UNIX.
Creating a directory exit
Describes how to create a directory exit in Transfer CFT UNIX.
Creating an accounting exit
Describes how to create an accounting exit in UNIX.
Transfer CFT 3.3.2 Installation Guide 175
7 Unix operations
Development kit contentsThe development kit used to integrate the Transfer CFT APIs is divided into several directories:
l <installdir>/lib/ containing all required libraries, in C, including:
l A libcftapi.a module: this library is required for any application using the Transfer CFT APIs
l A libcftexa.a module: this library is required for any application using the Transfer CFT directory exits
l A libcftexf.a module; this library is required for any application using the file EXITs
l A libcftexe.a module; this library is required for any application using the end of transfer EXITs
To generate a user application based on the Transfer CFT APIs and use the file exit function, you must link the following with the libcftapi.a and libexe.a libraries.
l <installdir>/runtime/src/capi/ containing a command entry and catalog query example
l <installdir>/runtime/src/exit/ containing simple examples of file exits, directory exits, and end of transfer exits
Creating an API applicationThe example provided below was designed for the cft-tcp.conf configuration example located in <installdir>/runtime/conf/. For this example, you should have already customized this file using the method described in Running Transfer CFT for the first time.
Application componentsThe <installdir>/runtime/src/capi subdirectory contains the:
l Sample source module, called apixmp1.c, which interacts with Transfer CFT. This program reads the Transfer CFT catalog and displays its contents in part or in full, depending on the restrictions set in the command line
l makefile compilation procedure, which uses the apixmp1.c sample source module to generate the APIXMPI executable file
The <installdir>/lib subdirectory contains the:
l libcftapi.a module required to use Transfer CFT APIs
To generate the APIXMP1 sample program, proceed as follows.
1. Access the <installdir>/runtime/src/capi directory.
2. Enter the command: make
Testing the configurationTo test the configuration, proceed as follows:
Transfer CFT 3.3.2 Installation Guide 176
7 Unix operations
1. Access the <installdir>/runtime/conf/ directory.
2. Generate the Transfer CFT internal datafiles using cftinit with one of the two proposed configuration files:
cftinit cft-tcp.conf
3. When the cftinit complete message is displayed, run Transfer CFT using the command:
cft start
4. When the CFTMAIN process ID is xxxxx message is displayed, perform one or more transfers:
CFTUTIL send part=BOSTON,idf=TXT
5. Check that the transfers are complete:
cftcatab
6. Run the sample program:
cd <installdir>/runtime/src/capi ; ./APIXMP1
Results: The result should correspond to the catalog contents:
PART=NEW YORK, IDT=<dynamic identifier>,IDF=TXTPART=BOSTON ,IDT=<dynamic identifier>,IDF=TXTAPIXMP1 _ 2 record(s) found
7. Stop Transfer CFT:
cft stop
Creating an exit fileThe example described in this topic was designed to operate using the cft-tcp.conf configuration example located in <installdir>/runtime/conf. For this example, you should have already customized the file using the instructions in Running Transfer CFT for the First Time.
Application componentsThe <installdir>/runtime/src/exit/ subdirectory contains:
l A sample source module, called exfxmp1.c, with its associated include file exfus.h
l This program demonstrates the various user functions:
l ALLOC_TYP: the EXIT allocates the file
l OPEN_TYP: the EXIT opens the file
l DATA_TYP: the EXIT writes or reads the file
l And so on
l The mk_cftexitf compilation procedure, which uses exfxmp2.c to generate the CFTEXITF program
The <installdir>/lib subdirectory contains the:
Transfer CFT 3.3.2 Installation Guide 177
7 Unix operations
l libcftexf.a module; this library allows you to use the Transfer CFT file EXITs
To generate the sample CFTEXITF application, proceed as follows:
1. Access the <installdir>/runtime/src/exit/ directory.
2. Enter the command:
make -f mk_cftexitf
Testing the exit 1. Access the <installdir>/runtime/conf/ directory.
2. Generate the Transfer CFT internal datafiles using the cftinit utility with the configuration file:
cftinit cft-tcp.conf
3. When the cftinit complete message is displayed, run Transfer CFT using the cftstart utility:
cftstart
4. When the CFTMAIN process ID is xxxxx message is displayed, run a transfer using the command:
CFTUTIL send part=BOSTON, idf=fic1
5. After a few seconds, you can check the transfer state by entering the following command. If the transfers have not terminated, repeat the cftcatab command.
cftcatab
6. Stop Transfer CFT using the cftstop utility:
cftstop
7. Examine the contents of the cft_log. sav file in the <installdir>/runtime/log/ directory and locate the messages inserted by the EXIT.
The files created in <installdir>/runtime/ are empty, as the sample EXIT is only a simulation.
Creating a directory exitThe following example was designed from a modified version of the cft-tcp.conf configuration example, located in <installdir>/runtime/conf. For this example, you should have customized at least one of these files, using the instructions in Running Transfer CFT for the first time.
PrerequisitesBefore running the directory exit test, you must make a few changes to the cft-tcp.conf file, depending on the type of network used.
1. Edit the relevant file using your text editor (vi for example) and perform the following operations.
2. In the edited file, locate the cftprot command. The following lines are displayed:
Transfer CFT 3.3.2 Installation Guide 178
7 Unix operations
cftprot id = PeSITCFT,
type = PESIT,
prof = CFT,
...
/*** exita = EXIT_A, ** See Operations Guide **/
mode = replace
3. Delete the comments (delimited by /* at the beginning and */ at the end).
When the operation is complete, you should obtain the following cftprot command:
cftprot id = PeSITCFT,
type = PESIT,
prof = CFT,
...
exita= EXIT_A,
mode = replace
4. Locate the cftexit command, commented as follows:
/*** see Users Guide ***
CFTEXIT ID = EXIT_A,
PARM = EXAPARM1,
LANGUAGE = C,
PROG = 'CFTEXITA',
TYPE = ACCESS,
MODE = REPLACE ***/
You must remove the comments to obtain the following command:
CFTEXIT ID = EXIT_A,
PARM = EXAPARM1,
LANGUAGE = C,
PROG = 'CFTEXITA',
TYPE = ACCESS,
MODE = REPLACE
5. Locate the communication properties of your site, which appear at the end of the file.
l If you are modifying the cft-tcp.conf file, you must also find every occurrence of the HOST string located in cfttcp-type commands and replace the X character strings with your system name or address
Transfer CFT 3.3.2 Installation Guide 179
7 Unix operations
Application componentsThe <installdir>/runtime/src/exit/ subdirectory contains:
l A sample source module, called exaxmpm.c, with its associated include file (exaus.h), and two additional files called exaxmpp.c and exaxmpp.h
This program is used to check the following features:
l Activation of a transfer to a partner known to the directory EXIT but not to Transfer CFT
l Activation of a transfer to a partner not known to either Transfer CFT or the directory EXIT
l The mk_cftexita compilation procedure used to generate the CFTEXITA program
The <installdir>/lib subdirectory contains:
l The libcftexa.a module required to use the Transfer CFT directory EXITs
To generate the sample CFTEXITA application, proceed as follows.
1. Access the <installdir>/runtime/src/exit/ directory.
2. Enter the command:
make -f mk_cftexita
Running the test 1. Access the <installdir>/runtime/conf directory.
2. Generate the Transfer CFT databases using cftinit the configuration file provided and modified for this EXIT: cft-tcp.conf
3. When the cftinit complete message is displayed, run Transfer CFT using the cftstart utility: cftstart
4. When the CFTMAIN process ID is xxxxx message is displayed, perform an initial standard transfer using the command:CFTUTIL send part=BOSTON, idf=TXT
5. Now submit a second transfer to the NCFT_OK partner.CFTUTIL send part=NCFT_OK,idf=TXT
6. After a few seconds, you can check the transfer state by entering thecommand: cftcatab
7. The transfer is successful because NRPART01 is defined in the DIRECTORY EXIT as being the EXTPTN01 non- Transfer CFT partner (see the exaxmpp.c file in <installdir>/runtime/src/exit/).
8. Now submit a third transfer to the NCFT_OK partner.CFTUTIL send part=NCFT_NOK,idf=TXT
9. After a few seconds, you can check the transfer state by entering thecommand:
cftcatab
Transfer CFT 3.3.2 Installation Guide 180
7 Unix operations
The transfer fails because the password is invalid, even though NRPART02 is defined in the DIRECTORY EXIT (see the exaxmpp.c file in <installdir>/runtime/src/exit/).
10. Stop Transfer CFT:
cftstop
Creating an accounting exitThis topic provides an example that was designed for a modified version of the cft-tcp.conf configuration example, located in <installdir>/runtime/conf. In addition to the sample EXITs provided in the <installdir>/runtime/src/exit subdirectory, this subdirectory contains a sample Transfer CFT accounting file query.
For this example, you should have customized at least one of these files, using the instructions in Running Transfer CFT for the first time.
Application componentsThe application comprises the following three modules:
l exacct.c: sample source
l cftcnt.h: description of the required structures
l mk_exacct: sample build makefile file
To build the application:
1. Access the <installdir>/runtime/src/exit directory.
2. Enter the command:make -f mk_exacct
When the compilation has been completed, an EXACCT executable file is created in the <installdir>/bin/ subdirectory.
Testing the fileThe name of the accounting file should be displayed as a parameter.
For example, you could write the following command to display the content of the alternate accounting file:
EXACCT $CFTACNTA
This example assumes that the file was compiled in pure ANSI:
l If your C compiler does not normally use the ANSI mode, refer to the manufacturer's documentation for the appropriate activation option.
l If your C compiler does not support the ANSI mode, you may have to adapt the example.
Depending on the system used, some data types may not be available:
Transfer CFT 3.3.2 Installation Guide 181
7 Unix operations
l If a compilation error arises because the MAX_PATH is incorrectly defined, add the following instruction to the beginning of the example:
#define ACCT_PATH_MAX
l If a compilation error arises because the uchar_t types are incorrectly defined, add the following instruction to the beginning of the file:
#define ACCT_UCHAR
l If a compilation error arises because the ssize_t types are incorrectly defined, add the following instruction to the beginning of the example:
#define ACCT_SSIZE
UNIX High Availability
About AIX and IBM HACMPThis sub-book describes how to install Transfer CFT and configure using AIX with IBM HACMP. This topic lists prerequisites and provides an overview of the system.
PrerequisitesSystem:
l AIX 5.3 and higher
Software:
l HACMP 4.4.1
l Transfer CFT
Preparing the environmentThe test environment comprises two nodes: hacmp1 and hacmp2.
For the virtual IP address, we defined the virtual IP of the Transfer CFT server for HACMP on our DNS. It is also possible to declare the virtual IP on each node of the cluster, in the /etc/hosts file. For our tests, we added the following line to this file:
172.17.50.57 cft-ip
This virtual cft-ip address must be declared on all the cluster nodes (hacmp1 and hacmp2 for our tests). Use it for our Transfer CFT service.
Shared File SystemsOn our cluster, the shared file system is /cft-vg. (group volume cftvg).
Transfer CFT 3.3.2 Installation Guide 182
7 Unix operations
It is possible to use several separate file systems to install the configuration, the scripts, the files to be sent and the files to be received.
Setting up the Transfer CFT scripts for HACMPThe scripts cftstartFailover and cftstopFailover are copied to the shared filesystem:
l cftstartFailover:
This script creates a backup and then recreates the logs and accounting files. It then restarts Transfer CFT
l cftstopFailover:
This script tries a normal Transfer CFT stop procedure, then cleans the environment
These scripts are available in the topic Transfer CFT Scripts of this document.
Transfer CFT installationThe process of installing Transfer CFT is the same as for installing Sun Cluster.
Transfer CFT server and HACMP
HACMP monitoring commands
Clstat
clstat : clstat [-c cluster ID] [ -r seconds] [-i]
Clstat indicates if the cluster is started, stopped, or in an unstable state. It also indicates if the nodes are in the process of joining or quitting the cluster, or if they are in reconfiguration. Operational details of each node are also displayed.
Example of ASCII operation
clstat - HACMP for AIX Cluster Status Monitor
---------------------------------------------
Cluster: axway (666) Thu Jan 15 18:00:37 NFT 2004
State: DOWN Nodes: 2
SubState: UNSTABLE
Node: hacmp1 State: DOWN
Interface: hacmp1-enboot (0) Address: 172.17.2.8
State: DOWN
Node: hacmp2 State: DOWN
Transfer CFT 3.3.2 Installation Guide 183
7 Unix operations
Interface: hacmp2-enboot (0) Address: 172.17.2.18
State: DOWN
************************ f/forward, b/back, r/refresh, q/quit***********
Clfindres
l clfindres: clfindres [-s] [resgroup1] [resgroup2] ...
clfindres displays the resource groups of the cluster.
Example of ASCII display
----------------------------------------------------------------
GroupName Type State Location
--------- ------ --------
CFT-rg: cascading UP hacmp1
---------------------------------------------------------------
Starting the service
Start-up service commands include:
l /usr/sbin/cluster/etc/rc.cluster
This script is called by inittab if "Start at system restart" has been selected in the smitty "Start Cluster Services" screen.rc.cluster executes verifications, starts the clinfo demon, then emits the command: /usr/sbin/cluster/utilities/clstart.
l /usr/sbin/cluster/utilities/clstart
Start HACMP with the options specified in the smitty "Start Cluster Services" screen.
Stopping the service
The stop service command is:
/usr/sbin/cluster/utilities/clstop
Stop HACMP services with the options specified in the smitty "Stop Cluster Services" screen.
Additional information for AIX/HACMPThis topic provides reference information for using Transfer CFT AIX with IBM HACMP.
Refer to the HACMP documentation for aid in creating virtual IP addresses and shared system files during cluster installation.
Transfer CFT 3.3.2 Installation Guide 184
7 Unix operations
Transfer CFT resources groupAll resources are include in the same group, named CFT-rg:
/usr/es/sbin/cluster/utilities/claddgrp -g 'CFT-rg' \-r 'cascading' -n 'hacmp1 hacmp2'
This group is activated or switched over to one of the nodes. This avoids having two Transfer CFT instances activated simultaneously on the cluster.
Command line description:
-g CFT-rg: resources group name-r 'cascading': cascading type-n 'hacmp1 hacmp2': names of the nodes used
Application server
Creating the cft-service:
/usr/es/sbin/cluster/utilities/claddserv –s ‘cft-service’ \–b ‘usr/es/sbin/cluster/local/cftstartFailover’ \–e ‘usr/es/sbin/cluster/local/cftstopFailover’
Command line description:
–s ‘cft-service’: service name–b ‘usr/es/sbin/cluster/local/cftstartFailover’: startup script–e ‘usr/es/sbin/cluster/local/cftstopFailover’: shutdown script
This service must be declared to the CFT-rg ressourcegroup:
/usr/es/sbin/cluster/utilities/claddres -g'CFT-rg' \NODE_PRIORITY_POLICY= SERVICE_LABEL='cft-ip' FILESYSTEM='/cft-vg' FSCHECK_TOOL='fsck' RECOVERY_METHOD='sequential' EXPORT_FILESYSTEM= MOUNT_FILESYSTEM= NFS_NETWORK= VOLUME_GROUP='cftvg' CONCURRENT_VOLUME_GROUP= DISK= AIX_CONNECTIONS_SERVICES= AIX_FAST_CONNECT_SERVICES= SHARED_TAPE_RESOURCES= APPLICATIONS='cft-service' TCP_CONNECTIONS= MISC_DATA= VG_AUTO_IMPORT='false' INACTIVE_TAKEOVER='false' CASCADE_WO_FALLBACK='false' DISK_FENCING='false' SSA_DISK_FENCING='false' FS_BEFORE_IPADDR='false'
About Solaris Sun cluster This sub-book describes the Transfer CFT installation and configuration with a Solaris Sun cluster. This topic describes the prerequisites and reference materials for installing a Solaris Sun cluster.
PrerequisitesSystem requirements:
Transfer CFT 3.3.2 Installation Guide 185
7 Unix operations
l Solaris 10
Software requirements:
l Sun Cluster 3.0 or 3.1
l Transfer CFT
Transfer CFT and Sun cluster integrationAxway used Generic Data Services (GDS) to test Transfer CFT integration with Sun Cluster.
The choice of GDS was based on:
l Rapid and direct integration with Sun Cluster
l Relative ease of configuration of GDS, requiring only three scripts: start, stop and test
l Transfer CFT already includes the scripts capable of executing the operations called by GDS
Sun Cluster operates under the root user. The scripts cftstartFailover, cftstopFailover and cftprobeFailover were developed to execute the cftstart, cftstop and cftping commands under the user ID for the Transfer CFT UNIX account user. These scripts are available in the sub-book Transfer CFT scripts.
To complete the setup of this installation, you must supply GDS with the list of listening addresses for Transfer CFT TCP/IP and the shared system.
Sun Cluster reference documentation
http://docs.sun.com/?q=sun+cluster
Installation prerequisitesThis topic describes the environmental prerequisites for installing an Transfer CFT Solaris Sun cluster.
Prerequisites
Virtual IP address
The virtual IP address of the Transfer CFT service for the Sun Cluster is defined for each node of the cluster in the file /etc/hosts. For our tests, we added the following line to this file: 172.17.50.50 cft-ip
Shared file systems
In our development and test cluster, the shared file system is: /global/cft.
You can use several separate file systems to install the configuration. These can include the GDS scripts, the files to be sent, and the files to be received.
Transfer CFT 3.3.2 Installation Guide 186
7 Unix operations
Setting up the Transfer CFT scripts for Sun Cluster
The scripts cftstartFailover, cftstopFailover and cftprobeFailover are copied to the shared file system:
l cftstartFailover:
This script creates a backup and then recreates the logs and accounting files. It restarts Transfer CFT when it has completed the task.
l cftstopFailover:
This script to attempts a normal Transfer CFT stop procedure, and cleans the environment.
l cftprobeFailover:
This script tests for the presence of Transfer CFT, and cleans the environment according to the cftping response.
Installing the Sun Cluster This topic describes the steps involved in installing the Sun Cluster with Transfer CFT.
Pre-installationBefore installing Transfer CFT, create accounts with the same user name on each node.
InstallationProceed with a normal Transfer CFT installation. Use the batch mode to deploy the product on the multiple cluster nodes.
Post-installation
After you install Transfer CFT you must modify and reinterpret the profile environment files, in order to share:
l Configuration files
l Transfer catalog
l Communications file
Example of a modified profile file
#--------------------------------------------
# Starting CFT configuration
# Fri Sep 26 17:28:32 MEST 2006
#----------------------------------------
CFTDIRINSTALL=/home/cft/cft
CFTDIRRUNTIME =/home/cft/cft/runtime
Transfer CFT 3.3.2 Installation Guide 187
7 Unix operations
CFTDIRAPI=$CFTDIRRUNTIME /src/capi/
CFTDIRDAT=$CFTDIRRUNTIME/data/
CFTDIREXIT=$CFTDIRRUNTIME/src/exit/
CFTDIRINS=$CFTDIRRUNTIME/conf/
CFTDIRLOG=$CFTDIRRUNTIME/log/
CFTDIRPUB=$CFTDIRRUNTIME/pub
CFTDIRSEC=$CFTDIRRUNTIME/conf/pki/
CFTHINI=$CFTDIRRUNTIME/data/sec.ini
CFTHPARM=$CFTDIRRUNTIME/data/secparm
CFTACNT=$CFTDIRRUNTIME/data/cft_acnt
CFTACNTA=$CFTDIRRUNTIME/data/cft_acnta
CFTLOG=$CFTDIRRUNTIME/data/cft_log
CFTLOGA=$CFTDIRRUNTIME/data/cft_loga
CFTCLUSTERSHARE=/global/cft/param
CFTPKIDIR=$CFTCLUSTERSHARE/pki
CFTPKU=$CFTCLUSTERSHARE/pki/pkibase
CFTCATA=$CFTCLUSTERSHARE/cft_cata
CFTCOM=$CFTCLUSTERSHARE/cft_com
CFTPARM=$CFTCLUSTERSHARE/cft_parm
CFTPART=$CFTCLUSTERSHARE/cft_part
PATH=$PATH:$CFTDIRINSTALL/bin:$CFTDIREXIT:$CFTDIRAPI
export PATH
export CFTDIRINSTALL CFTDIRRUNTIME CFTDIRAPI CFTDIRDAT CFTDIREXIT CFTDIRINS
export CFTDIRLOG CFTDIRPUB CFTDIRSEC
export CFTHINI CFTHPARM CFTPKIDIR
export CFTPKU CFTACNT CFTACNTA CFTCATA CFTCOM CFTLOG CFTLOGA
export CFTPARM CFTPART
export CFTCLUSTERSHARE
#-------------------------------------------
# CFT configuration completed
Transfer CFT 3.3.2 Installation Guide 188
7 Unix operations
# Fri Sep 26 17:28:35 MEST 2003
#-----------------------------------------
CFTCLUSTERSND=/global/cft/snd
CFTCLUSTERRCV=/global/cft/rcv
export CFTCLUSTERSND CFTCLUSTERRCV
Transfer CFT configuration 1. Configure the virtual IP of the cluster in the cftnet card:
cftnet id = TCPIP,type = TCP,call = inout,host = 172.17.50.57, /* virtual IP of the cluster */maxcnx = 3,mode = replace
2. Enter the paths to the shared system files for the files to be sent or received.
Sun cluster service configurationThis topic describes the Transfer CFT Sun cluster service configuration configuration parameters and resource controls.
To integrate Transfer CFT with Sun cluster, use the SCRGADM command to record and remove resources.
About the scrgadm commandEnter the command as follows:
scrgadm -p[v[v]] [-t <Resource_Type_name>] \[-g <Resource_Group_name>] \[-j <Resource_name>]scrgadm -a -t <Resource_Type_name> [-f <RT_registration_file_path>] \[-h RT_installed_node_list]scrgadm -c -t <Resource_Type_name> -h RT_installed_node_listscrgadm -r -t <Resource_Type_name>scrgadm -a | -c -g <Resource_Group_name> [-h RT_installed_node_
list][-y <property>]scrgadm -r -g <RG_name>scrgadm -a -j <Resource_name> -t <Resource_Type_name> \-g <RG_name> [-y <property> [-y <property>]] \[-x <property> [-x <property>]]scrgadm -c -j <Resource_name> [-y <property> [-y <property>]] \[-x <property> -x <property>]]
Transfer CFT 3.3.2 Installation Guide 189
7 Unix operations
scrgadm -r -j <Resource_name>scrgadm -a -L -g <LogicalHost_RG_Name> [-j <Resource_name>] \-l hostname[,hostname,...] [-n nafo@node[,nafo@node,...]][-y <property> [-y <property>]]scrgadm -a -S -g <SharedAddress_RG_Name> [-j <Resource_name>] \-l hostname[,hostname,...] [-n nafo@node[,nafo@node,...]] \[-X aux_node[,aux_node,...]] [-y <property> [-y <property>]]
Transfer CFT resources group
All resources are included in the same group, named CFT-rg:
scrgadm –a –g CFT-rg
This group is activated or switched over to one of the nodes, to avoid having two Transfer CFT instances activated simultaneously on the same cluster.
View the command line description
Command Description
-a resource addition (add)
-g CFT-rg resources group name
Transfer CFT resources
There are three resources for the CFT-rg group:
l Virtual IP
l Shared file system
l GDS: the Transfer CFT start, stop, and test scripts
Virtual IPThe public interface support has changed between the versions 3.0 and 3.1 of Sun Cluster. Consequently, the declaration of the virtual IP is different between the two versions. The following interface types are used:
l NAFO, Network Adapter Fail Over, for SC 3.0
l IPMP, IP MultiPathing, for SC 3.1
The virtual IP is added as follows on Sun Cluster version 3.0:
scrgadm –a –L –g CFT-rg –j cft_ip –l cft-ip –n nafo0@1,nafo0@2
For Sun Cluster 3.1 the command is:
scrgadm –a –L –g CFT-rg –j cft_ip –l cft-ip –n ipmp0@1,ipmp0@2
View the command line description
Transfer CFT 3.3.2 Installation Guide 190
7 Unix operations
Command Description
-a resource addition (add)
–L logical name resource type
-g CFT-rg resources group name
-j cft-ip resource name
–l cft-ip logical name (as defined in /etc/hosts in our test)
-n nafo0@1,nafo0@2 use of nafo interfaces 1 and 2
Shared file systemThese tests were performed using a single shared file system. It is declared as follows:
scrgadm –a –g CFT-rg –t SUNM.HAStoragePlus –j cft-disk \–x FilesystemMountpoints=/global/cft
View the command line description
Command Description
-a resource addition (add)
-g CFT-rg resources group name
-t SUNW.HAStoragePlus GDS resource type
-j cft-disk resource name
-x FilesystemMountpoints=/global/cft mount point
Generic data service CFTThe following is the declaration of the GDS for Transfer CFT:
scrgadm –a –g CFT-rg –t SUNW.gds –j cft-gds \–x Start_command=/global/cft/cftstartFailover \–x Stop_command=/global/cft/cftstopFailover \–x Probe_command=/global/cft/cftprobeFailover \–y Port_list="1765/tcp,1766/tcp,1767/tcp" \–y Resource_dependencies=cft-ip,cft-disk
View the command line description
Transfer CFT 3.3.2 Installation Guide 191
7 Unix operations
Command Description
-a resource addition (add)
-g CFT-rg resources group name
-t SUNW.gds GDS resource type
-j cft-gds resource name
-x Start_command= /global/cft/cftstartFailover
command definition for startup
-x Stop_command= /global/cft/cftstopFailover
command definition for stop
-x Probe_command= /global/cft/cftprobeFailover
command definition for probe
–y Port_list=1765/tcp verification of the listening ports of Transfer CFT in TCP (parameters of the Transfer CFT cftprot cards)
–y Resource_dependencies= cft-ip,cft-disk
You can activate GDX on a node only if the cft-ip and cft-disk resources are online. In the event of problems with one of these two resources, Sun Custer attempts to restart the faulty resource, or to switch over to another node
The default parameters are adequate for the test environment.
Sun cluster service configuration commandsSun Cluster services are managed and monitored using the following service configuration commands:
l scswitch for startup, stop, and switch over
l scstat for monitoring
Sun cluster scswitch command
The commands are as follows:
scswitch -z -g resource_grp[,...] -h node[,...]
scswitch -z -D device_group_name[,...] -h node
scswitch -S -h from_node
scswitch -R -h node[,...] -g resource_grp[,...]
scswitch -m -D device_service_name[,...]
Transfer CFT 3.3.2 Installation Guide 192
7 Unix operations
scswitch -e | -n [-M] -j resource[,...]
scswitch -u | -o -g resource_grp[,...]
scswitch -c -h node[,...] -j resource[,...] -f flag_name
scswitch -Z [-g resource_grp[,...]]
scswitch -F -g resource_grp[,...] | -D device_group_name[,...]
scstat [-DWgnpqi] [-v[v]] [-h <host>]
The following sections describe the commands necessary to monitor, start, stop and switchover services. Refer to the Sun documentation and the "man" pages for additional details.
Sun cluster scstat command
Example of scstat exit :
root@chou # scstat
-Resource Groups --
Group Name Node Name State
---------- --------- -----
Group: xos-rg chou Online
Group: xos-rg fleur Offline
Group: pel-rg chou Online
Group: pel-rg fleur Offline
Group: CFT-rg chou Offline
Group: CFT-rg fleur Online
-- Resources --
Resource Name Node Name State Status Message
------------- --------- ----- --------------
Resource: xos-disk chou Online Online
Resource: xos-disk fleur Offline Offline
Resource: ops-ip chou Online Online - LogicalHostname online.
Resource: ops-ip fleur Offline Offline
Resource: xos-sm chou Online Online
Resource: xos-sm fleur Offline Offline
Resource: xos-sp chou Online Online
Transfer CFT 3.3.2 Installation Guide 193
7 Unix operations
Resource: xos-sp fleur Offline Offline
Resource: pel-ip chou Online Online - LogicalHostname online.
Resource: pel-ip fleur Offline Offline - LogicalHostname offline.
Resource: pel-disk chou Online Online
Resource: pel-disk fleur Offline Offline
Resource: pel-gds chou Online Online
Resource: pel-gds fleur Offline Offline
Resource: cft-ip chou Offline Offline - LogicalHostname offline.
Resource: cft-ip fleur Online Online - LogicalHostname online.
Resource: cft-disk chou Offline Offline
Resource: cft-disk fleur Online Online
Resource: cft-gds chou Offline Offline
Resource: cft-gds fleur Online Online
---------------------------------------------------------------
Starting the serviceThe following command activates the Transfer CFT-rg service:
scswitch –Z –g CFT-rg
View the log extract for starting Transfer CFT on a node
Oct 10 18:35:18 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hafoip_prenet_start> for resource <cft-ip>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18:35:18 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hafoip_prenet_start> completed successfully for resource <cft-ip>, resource group <CFT-rg>
Oct 10 18:35:18 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hastorageplus_prenet_start> for resource <cft-disk>, resource group <CFT-rg>, timeout <1800> seconds
Oct 10 18:35:20 fleur Cluster.Framework: [ID 801593 daemon.notice] stdout: becoming primary for dsk/d16
Oct 10 18:35:20 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hastorageplus_prenet_start> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Transfer CFT 3.3.2 Installation Guide 194
7 Unix operations
Oct 10 18:35:20 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hafoip_start> for resource <cft-ip>, resource group <CFT-rg>, timeout <500> seconds
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hafoip_start> completed successfully for resource <cft-ip>, resource group <CFT-rg>
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hafoip_monitor_start> for resource <cft-ip>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hastorageplus_start> for resource <cft-disk>, resource group <CFT-rg>, timeout <90> seconds
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hafoip_monitor_start> completed successfully for resource <cft-ip>, resource group <CFT-rg>
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hastorageplus_start> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <hastorageplus_monitor_start> for resource <cft-disk>, resource group <CFT-rg>, timeout <90> seconds
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <gds_svc_start> for resource <cft-gds>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18:35:21 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <hastorageplus_monitor_start> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Oct 10 18:35:31 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <gds_svc_start> completed successfully for resource <cft-gds>, resource group <CFT-rg>
Oct 10 18:35:31 fleur Cluster.RGM.rgmd: [ID 707948 daemon.notice] launching method <gds_monitor_start> for resource <cft-gds>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18:35:31 fleur Cluster.RGM.rgmd: [ID 148023 daemon.notice] method <gds_monitor_start> completed successfully for resource <cft-gds>, resource group <CFT-rg>
Stopping the service
The following command deactivates the Transfer CFT resources. To stop Transfer CFT, deactivate the cft-gds resource. When you stop Transfer CFT using cft stop, an automatic restart of Sun Cluster is triggered.
Transfer CFT 3.3.2 Installation Guide 195
7 Unix operations
scswitch –n –j cft-gdsscswitch –n –j cft-ipscswitch –n –j cft-disk
View the log extract for stopping Transfer CFT on a node
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <hafoip_monitor_stop> for resource <cft-ip>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <hastorageplus_monitor_stop> for resource <cft-disk>, resource group <CFT-rg>, timeout <90> seconds
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <gds_monitor_stop> for resource <cft-gds>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <hastorageplus_monitor_stop> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <hafoip_monitor_stop> completed successfully for resource <cft-ip>, resource group <CFT-rg>
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <gds_monitor_stop> completed successfully for resource <cft-gds>, resource group <CFT-rg>
Oct 10 18 :36 :34 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <gds_svc_stop> for resource <cft-gds>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <gds_svc_stop> completed successfully for resource <cft-gds>, resource group <CFT-rg>
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <hastorageplus_stop> for resource <cft-disk>, resource group <CFT-rg>, timeout <1800> seconds
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <hastorageplus_stop> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <hafoip_stop> for resource <cft-ip>, resource group <CFT-rg>, timeout <300> seconds
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <hafoip_stop> completed successfully for resource <cft-ip>, resource group <CFT-rg>
Transfer CFT 3.3.2 Installation Guide 196
7 Unix operations
Oct 10 18 :36 :44 fleur Cluster.RGM.rgmd : [ID 707948 daemon.notice] launching method <hastorageplus_postnet_stop> for resource <cft-disk>, resource group <CFT-rg>, timeout <1800> seconds
Oct 10 18 :36 :45 fleur Cluster.RGM.rgmd : [ID 148023 daemon.notice] method <hastorageplus_postnet_stop> completed successfully for resource <cft-disk>, resource group <CFT-rg>
Oct 10 18 :36 :46 fleur Cluster.Framework : [ID 801593 daemon.notice] stdout : no longer primary for dsk/d16
Switch overs
Switch-over the service to the "fleur" node:
scswitch –z –g CFT-rg –h fleur
Specific Transfer CFT configurations
Unix-specific valuesThis topic summarizes Transfer CFT characteristics that differ from other operating systems:
l specific values
l default files
l filename extensions
Specific values tables
Notation Object Value
char_file Prefix to logical names _ (underlined)
char_mask Wild card character ? char_unit Separator (volume) none char_symb Prefix to symbolic variables & char_directory Character introduced in the path name of the FNAME
parameter (CFTRECV) from which a tree structure can be created
+
file_symb Character introducing a file name sent to CFTUTIL in parameter form
@
Transfer CFT 3.3.2 Installation Guide 197
7 Unix operations
Names of default files used by CFTUTIL
Objet Default name
Parameters file _CFTPARM
Partners file _CFTPART
Catalogc file _CFTCATA
Log file _CFTLOG
Communication media _CFTCOM
statistics file _CFTACNT
Preferred media File
Transferable files This topic describes the Transfer CFT parameters that are specific to UNIX concerning the characteristics of a transferable file.
l Characteristics of files automatically detected (or not) on transmission
l FTYPE and FCODE values implicitly associated during transmission
l FTYPE and FRECFM values on receipt
Characteristics of files automatically detected on transmission
Parameter Automatically detected on transmission
FSPACE YES
FLRECL NO
FBLKSIZE NO
FRECFM NO
FTYPE NO
Transfer CFT 3.3.2 Installation Guide 198
7 Unix operations
FTYPE values and FCODE values implicitly associated during transmission
FTYPE FCODE Type of sent file
‘ ‘ BINARY Binary
B BINARY Binary
V BINARY Binary file emulating locally a variable file format
T ASCII Text file with LF or CRLF as end-of-line separator
O ASCII Text file with CRLF as end-of-line separator
X ASCII Text file with LF as end-of-line separator
J ASCII Stream textUsing stream text (J) allows a text type file to be sent that contains records that exceed 32 KB. As opposed to text type (FTYPE=T), stream text does not add an EOL sequence (LF or CRLF) to the received file.When using stream text (FTYPE=J), the sender and the receiver must both have the FTYPE set to J. Setting only the sender or receiver to FTYPE=J results in unexpected content for the transferred file.
FTYPE = J refers to stream text. The stream text type allows sending a text file that contains records that are larger than 32 KB. Unlike classical text types (T, O, X) the stream text type does not add an EOL sequence (LF or CRLF) at the end of the received file.
Note FTYPE J is available in Transfer CFT Transfer CFT 3.0.1 SP7 (UNIX and Windows) and higher.
FTYPE and FRECFM values on receipt
FTYPE FRECFM Type of received file
B F Binary fixed-length sequential file
B U /V Binary sequential file
V V Binary file emulating locally a variable file format
T F Fixed-length sequential text file with LF as end-of-line separator
Transfer CFT 3.3.2 Installation Guide 199
7 Unix operations
FTYPE FRECFM Type of received file
T U /V Variable length sequential text file with LF as end-of-line separator
O F Fixed-length sequential text file with CRLF as end-of-line separator
O U/V Variable length sequential text file with CRLF as end-of-line separator
X F Fixed-length sequential text file with LF as end-of-line separator
X U/V Variable length sequential text file with LF as end-of-line separator
J U/V Variable length sequential text file with LF as end-of-line separator
These values are either given explicitly in the CFTRECV command or deduced from the protocol values received.
l On request Transfer CFT performs an access control on the files transferred. It determines, for example, if the initiator of the send request has read access rights on the file to be sent.
l On receipt, Transfer CFT creates the file if it does not exist.
l The organization, FORG, of the files sent or received by Transfer CFT is sequential.
Transfer CFT 3.3.2 Installation Guide 200
Deployment packages
Create a product deployment package A product deployment package in Transfer CFT is called an ExpressPackage.
The Express Package section describes how to create a reusable and distributable Transfer CFT package to simplify and ease the task of installing and configuring Transfer CFTs on multiple servers of the same architecture.
Note You can only install a Transfer CFT Express Package on the same platform as the one on which it was generated. For example, a Transfer CFT Express Package that is generated on linux-x86-64 can only be installed on a linux-x86-64 platform.
The procedure consists of:
l Installing a template Transfer CFT 3.3.2
l Configuring as required to meet your business needs
l Generating an Express Package that is based on the configured template
l Optionally customizing the Express Package
l Deploying and installing the Express Package
Install a template Transfer CFTBegin by installing a Transfer CFT instance, and configure as required to meet your business needs. This configured Transfer CFT serves as the template for the Express Package you are about to create.
Configure the:
l Static configuration, such as protocols (CFTPROT), networks (CFTNET), UCONF parameters, and so on
l Partners (CFTPART, CFTTCP) Note: If you create partners to export, DO NOT use the NSPART parameter in the CFTPART definition. The target Transfer CFT will instead use the CFTPARM PART/NPART values.
l Flows (CFTSEND and CFTRECV)
l SSL certificates
l Processing scripts and EXITs
l Additional Axway components that you use with Transfer CFT, such as Central Governance
Note You can embed the contents of the CFTDIRRUNTIME/bin and CFTDIRRUNTIME/exec directories in the generated Express Package.
Transfer CFT 3.3.2 Installation Guide 201
Generate the Express PackageTo generate an Express Package from the template Transfer CFT:
1. Stop the Transfer CFT instance.
2. Navigate to the Axway installation directory of the template Transfer CFT, and run the Installer in configuration mode.
The default Axway installation directory is $HOME/Axway.
Run the configure.sh script.
3. The Installer wizard displays. In the Welcome page select Next.
4. In the Configuration Type page, select Create an Express Package. Click Next to continue.
5. Specify the file name of the Transfer CFT installation package that you used to install the Transfer CFT template. The package name format is Transfer_CFT_<version>_Install_<platform>_BN<buildNumber>.zip.
6. Optionally, specify the file name of the service pack and/or patch to embed in the Express Package.
o The format of the service pack name is Transfer_CFT_<version>_SP<SPNumber>_<platform>_BN<buildNumber>.jar.
o The format of the patch name is Transfer_CFT_<version>_Patch<PatchNumber>_<platform>_BN<buildNumber>.jar.
7. Enter the path to the location where you want the new Express Package to be saved once generated.
8. Click Next to continue.
9. Select the configuration elements that you want to include in the Express Package, such as the partners and parameters database, the UCONF parameters, and the local PKI database. Click Next to continue.
Note 1: If you are using Central Governance, you should only include the UCONF parameters and the local PKI database. The other configuration elements are deployed by Central Governance.
Note 2: If you selected the auto import feature during the Transfer CFT template installation, you can only include the CFTDIRRUNTIME/bin and CFTDIRRUNTIME/exec contents.
10. In the Configuration confirmation page, click Configure to generate the Express Package.
ResultsThe Express Package, Transfer_CFT_<version>_ExpressPackage_<platform>_<timestamp>.zip, is generated and located in the directory you selected in the previous steps.
Transfer CFT 3.3.2 Installation Guide 202
Customize the Express Package You can customize the Transfer CFT Express Package prior to deploying and installing it. The Transfer CFT Express Package is nearly the same as the Transfer CFT Install package, the only difference being the additional ExpressPackage directory. If you are not customizing the Express Package (for example the installation directories), you can skip this section.
The ExpressPackage directory contains the:
l data directory: This directory contains the data exported from the Transfer CFT template.
o bin directory: This directory contains all files retrieved from CFTDIRRUNTIME/bin.
o exec directory: This directory contains all files retrieved from CFTDIRRUNTIME/exec.
o pki directory: This directory contains all exported certificates.
o cft-parm.cfg: This file contains all of the parameter database objects (CFTPARM, CFTCAT, CFTLOG, CFTSEND, CFTRECV, and so on).
o cft-part.cfg: This file contains all of the exported Transfer CFT partner database objects (CFTPART, CFTTCP, and so on).
o cft-cftparm.cfg: This file contains only the CFTPARM objects to be imported during the Express Package installation.
o cft-uconf.cfg: This file contains any UCONF parameters that were configured in the template Transfer CFT.
o cft-pki.cfg: This file contains all of the PKICER commands to be executed during the Transfer CFT Express Package installation.
l expressPackage.properties: This file contains all of the installation parameters that can be overwritten. All parameters are documented within this file. To personalize any of these parameters, uncomment the respective line and add the new value.
l install executable: The executable to install the Express Package.
To customize the Express Package before deploying it:
1. Unzip the package to a temporary directory, for example tempdir.
unzip Transfer_CFT_<version>_ExpressPackage_<platform>_<timestamp>.zip –d tempdir
2. Edit the expressPackage.properties file located in the ExpressPackage directory, for example tempdir/ExpressPackage. Customize installation parameters as needed.
Transfer CFT 3.3.2 Installation Guide 203
3. Rezip the package.
cd tempdir; zip -r Transfer_CFT_<version>_ExpressPackage_<platform>_<timestamp>_new.zip *
Example: Install Transfer CFT in a different directory In this example, the Transfer CFT template was installed in the /home/cft/Axway/Transfer_CFT directory.
To install Transfer CFT in a different directory on the target server, edit the expressPackage.properties file, uncomment, and set the Axway_InstallDir, CFT_InstallDir, CFT_RuntimeDir , CFT_Crypto_KeyFilename, and CFT_Crypto_SaltFilename parameters.
Axway_InstallDir = /opt/Axway
CFT_InstallDir = /opt/Axway/Transfer_CFT
CFT_RuntimeDir = /opt/Axway/Transfer_CFT/runtime
CFT_Crypto_KeyFilename = /opt/Axway/Transfer_CFT/runtime/data/crypto/crypkey
CFT_Crypto_SaltFilename = /opt/Axway/Transfer_CFT/runtime/data/crypto/crypsalt
Example: Install Transfer CFT in the home directory of different user accountsIn this example, the Transfer CFT template was installed on server0 by the user account test, in the /home/test/Axway/Transfer_CFT directory.
You can install the Transfer CFT on a target server in the home directory of different user accounts in a generic way using environment variables. Edit the expressPackage.properties file, uncomment, and set the Axway_InstallDir, CFT_InstallDir, and CFT_RuntimeDir parameters as follows.
Axway_InstallDir = $HOME/axway
CFT_InstallDir = $HOME/axway/cft
CFT_RuntimeDir = $HOME/axway/cft/runtime
Install the Express Package To deploy and install the Express Package:
1. Upload the generated Transfer_CFT_<version>_ExpressPackage_<platform>_<timestamp>.zip file to the target server.
2. Unzip the package.
3. Browse to the ExpressPackage directory located within the unzipped package.
Transfer CFT 3.3.2 Installation Guide 204
4. Add the execution rights to the install executable.
chmod +x install
5. Run the install executable.
Note If you run the install without an argument, the install executable uses the expressPackage.properties file, in the ExpressPackage directory, as the customization file. In command line you can specify a different file name using the following OS-specific syntax.
./install <file name>
Limitations l Transfer CFT Express Package does not support cluster mode installations.
l Transfer CFT Express Package cannot embed a Transfer CFT upgrade pack.
Transfer CFT 3.3.2 Installation Guide 205