Problem

Once the customer makes an unsuccessful attempt to upgrade from v3.3.2 to v3.6 (or higher) the installer is no longer available,

Subsequently in future retry upgrade, the installer does not detect the existing CFT (to be upgraded) and instead of switching to upgrade mode it often switches to install mode.

Resolution

The only solution is to go through a fresh installation of CFT, migrate the old configuration from the existing version and register CFT in CG if the customer uses CG, find below steps :

Steps

1 Package

The latest package of SP in GA of V36 should be used.

It can be downloaded in the Axway’s official web site. It should be unzipped in a separate folder from CFT installation.

The package includes all necessary elements for whole CFT V36 and the SP. Once the package is unzipped, the installation program can be run, for

• Installation
• Migration from V332
• Upgrade from a lower SP
• Rollback from a higher SP

2 Backup

Stop cft and copilot before the backup.

2.1 Backup for rollback

Once migrated, the Shared Runtime Directory (cft.runtime_dir ) and installation directory (cft.install_dir ) will be overwritten. Additionally, it will not be possible to roll back after the upgrade from a version lower than 3.4 is completed. The upgrade removes the old Axway Installer and all its contents.

So it's recommended to back up the content of cft_runtime_dir, cft.install_dir , and the directory of Axway Synchrony installer.

For CFT V332, release information is stored by Axway Synchrony installer, so that if it’s not possible to have that component, the automatic upgrade is not possible. A new CFT installation (with V36) is needed with import of CFT objects from the old installation.

2.2 Backup for import by a new installation

• Get the CFT objects:
  • cftutil cftext type=all, fout=ext.txt
• and uconf:
  • cftutil listuconf > uconf.txt

With these 2 outputs (ext.txt and uconf.txt), study what are specific files which are needed by a new installation.

For examples:

• Xlate files
• Scripts for pre and post transfers
• Other scipts
• Cron jobs
• Cft.key
• ……

Pay attention, from CFT parameters, it’s not possible to know if there are “sub” scripts called by scripts.

• If the customer uses EXITEOT program, the code source is needed as the recompile is necessary.
• A backup of flows related should be done in CG if the CFT is connected to a CG
• Backup the main configuration and UCONF parameters :
  • CFTUTIL CFTEXT type=all, fout=/opt/backup_conf/cft-extract.conf
• Backup the PKI certificates :
  • PKIUTIL PKIEXT fout=/opt/backup_conf/pki-extract.conf

Save all files created in the export folder having USER*, ROOT* KPRIV* or KPUB*, those are certificates and keys used for file transfer and CG communication

• If need to backup catalog and cftcom file:
• Catalog:
  • CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_filename_former_cft>, ofname=catalog_output.xml
• Communication media files:
  
  • CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_former_cft>, ofname=com_output.xml
• For USERCTRL=YES under Unix, ensure that the file $CFTDIRINSTALL/bin/cftsu_setup can be overwritten by CFT user.

3 Installation

• If CFT is registered in CG, remove it from CG product list.
• Use a new shell session (new cmd box in Windows). Do not launch profile of the old installation. If CFT environmental variables are set, they have to be reset to empty.

3.1 Installation of a new CFT V36

When the installation program is launched, if it proposes to do a new installation, it means either the installdir <installdir> is wrongly given, or the data in old Axway Installer is corrupted.

Sometimes for these cases a new installation is a must-be.

• Before launching the installation program, the folder for the installation has to be empty. Then a new CFTV36 may be installed into the same folders as the old one.
• initialize.properties can be customized and used. The CryptoKey_Password needto be set. Catalog_File_Size & Communication_File_Size, like other parameters can also be set.

Error message given by the installation program are sometime not very clear. For example, “runtime directory creation error” may be due to no set of CryptoKey_Password.

When running into trouble, sometime the installation will write unachieved commands into runtime.cmd and service.cmd in home directory. These scripts would be executed next time during installation and will create conflict. In the case of redo the complete installation, these scripts should be deleted.

3.1.1 Testing new CFT installation

When installation is achieved, the cft.key file can be copied from the backup. Then a loop transfer may be tested with cftutil send part=paris,idf=txt.

This step (starting CFT and doing a loop transfer) can only be performed in the current stage (just after a fresh new installation). After any change of CFT configuration, this test might cause problems, in particular when USERCTRL=YES.

4 After achievement of installation

4.1 Restore the configuration used by the old installation

This step is not needed in the case of upgrade mode.

For a new installation, the old configuration should be restored.

• Restore crons, xlate scipts, key file … from the backup place.
• Load the profile: ./profile
• Import the main configuration and UCONF parameters
  • In runtime folder run CFTINIT cft-extract.conf Cftinit command will create new CFT bases with the configuration from the parameter file in input. CFTCATA and CFTCOM files will be also recreated. It’s not recommended to run “cftutil @cft-extract.conf”. Because in this case, the default configuration will be kept if not updated, and may cause some issues.
• Import the PKI certificates
  • Copy all files having USER*, ROOT*, KPRIV* or KPUB*, to the folder where the following PKI command will be executed: PKIUTIL @pki-extract.conf If needed, the PKI base can be recreated by the command pkiutil pkifile fname= '%env:CFTPKU%',mode=replace
• In case the customer wants to restore the CFTCOM and CFTCAT
  • CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=<catalog_filename_new_cft > CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_filename_new_cft >

4.2 Migration of folder monitoring defined in UCONF

This step is automatically done by installation program for upgrade mode. For a new installation, when uconf is restored, it’s recommended to migrate manually folder monitoring from uconf to CFTFOLDER object. For Unix environment, if USERCTRL=YES, the migration (from uconf to CFTFOLDER object) is mandatory.

• Create CFTFOLDER objects in fm1.cfg file:
  • cftmifm migrate -o fm1.cfg
• Save uconf folder configuration:
  • CFTUTIL CFTEXT type=uconf,id=folder_monitoring.*,fout=fm_uconf_save.cfg
• Interpret fm1.cfg file:
  • CFTUTIL config type=input,fname=fm1.cfg
• Purge uconf folder configuration:
  • cftmifm purge

4.3 Case USERCTRL=YES (dispends of customer conf)

Under Unix, if in CFTPARM, USERCTRL is set to yes, CFTSU or CFTSUD has to be migrated manually. In CFT documentation, this is well explained. The steps can be followed:

Using system users UNIX (axway.com)

4.4 Testing CFT with imported configuration

Now it’s possible to make tests, to see if CFT can be started and if transfers can achieve.

• Ensure that the Unix shell session is not under root user.
• Start CFT
• Submit a transfer

4.5 Restore the connection with CG

4.5.1 Registration to CG

If the old CFT is connected to CG, after manual upgrade/install, It’s necessary to register the CFTV36 to CG:

• Reset cg.registration_id
  • cftutil uconfset id=cg.registration_id, value=-1
• Other uconf parameters need to be check. If necessary, following command need to be used:
  • CFTUTIL uconfset id=cg.enable, value=yes
  • CFTUTIL uconfset id=cg.shared_secret, value=xxxxxxxx
• If needed, the following commands are for importing root CA used by CG:
  • PKIUTIL pkicer id = 'CG_CA', iform = 'DER', iname = '/home/axway/CFT38/runtime/conf/pki/Governance_Root.cer', itype = 'ROOT', ROOTCID = 'CG_CA', state = 'ACT', mode = 'Replace'
  • cftutil uconfset id=cg.ca_cert_id, value=CG_CA
• Then starting copilot, the registration will be performed automatically, and CFT will connect to the CG.
  • Copstart
• A classical error in registration is that now CG doesn’t accept 2 CFTCOM definitions with file type, which was not the case for previous releases. If the error appears (clear message in CG), removing the CFTCOM unused in CFTPARM will resolve the issue.
• 2 things to be checked in CG: status of the CFT, and if the log of CFT can be listed in CG.
  • If the log of CFT can’t be seen and in copui.trc there is error message “SslMainProcess : session initialization error”, that may mean the key (for SSL connection) used in CFTV332 is corrupted.

To confirm:

- CFTUTIL UCONFSET ID=copilot.trace.ssl.level, VALUE=DBG

- copstop; copstart

- check if there is a line like this in copui.trc , if yes, it’s a known issue:

20201012 06332385 DBG SSL PID=32439 SslSessionInitialize : Failed set private key: ssl code 185073780, error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch (c/src/sslmng/sslsrv.c:215) [SslSessionInitialize]

To fix:

The certificate should be renewal with a new key:

- CFTUTIL UCONFSET ID=cg.certificate.governance.key_len, VALUE=4096 (or 2048 if it's already 4096, changing the length of the key to force the key renewal)

- CFTUTIL UCONFSET ID= cg.certificate.governance.renewal_datetime, VALUE="20200101000000"

- copstop ; copstart

4.5.2 Restore flows in CG

Flow should be restored from the backup.

End of process