Skip to main content

Hi IFS Community,
 

We have two remote instances named UAT and PROD. We are currently on IFS Cloud 22R2 SU5. The SFTP reader/sender is configured on UAT environment and public/private key-based authentication is set up between the middle-tier cluster and the SFTP server. The SFTP reader and the sender was working without any issues since the initial setup was completed.

Recently we performed a database refresh on UAT using the PROD database backup. After the database refresh(clone) activity, We updated the SFTP reader, sender configuration on the UAT environment again.(updated the “knownhost” file, private key file and other configurations on the application)


However we noticed on the log files obtained from the ifsapp-connect pods, that the connection attempt from the container to the SFTP server using the private key file has not been successful. 

ifsapp-connect logs:-
2023-11-03 09:49:27,370 SEVERE Eifs.Integration] (EE-ManagedExecutorService-ConnectReader-Thread-8) Initializating SFTP Reader eSFTP_READER1]...
 2023-11-03 09:49:27,371 SEVERE Sifs.Integration] (EE-ManagedExecutorService-ConnectReader-Thread-8) Building SftpClient at eintsftp.stengglink.com:22]
 2023-11-03 09:49:27,382 SEVERE ifs.Integration] (EE-ManagedExecutorService-ConnectReader-Thread-8) PKI based authentication, using Identity file: /opt/ifs/instance/INST1/conf/sftp/prvkeyfiles/identity8770.txt
 2023-11-03 09:49:27,448 SEVERE 8ifs.Integration] (EJB default - 1) Restoring previous Logger
 2023-11-03 09:49:27,448 SEVERE 4ifs.Integration] (EJB default - 1) Calling nativeClose()...
 2023-11-03 09:49:27,448 SEVERE 4ifs.Integration] (EJB default - 1) Fatal error in timer rREADER:SFTP_READER1] count=40 delay=600000

We checked the private key file inside the ifsapp-connect container as well and newly added knownhost file and private key files was available inside the container.

We also noticed that using that same private key file from the middle-tier host, we can make the connection to the SFTP server. Hence, it seems not to be an issue with the private key file.

 

Has anybody encountered this situation before?
We are looking for any recommendations to rectify this issue. 

Kind regards,
Herath

@sherath in this case It would be worth to check the SFTP server logs, and check if the requests from IFS outbound IP are reaching.

Hi @sherath 

maybe the paths of your key file, knownhost file etc. are not exactly the same.

Please compare these in your sender and reader in IFS Connect. 

@sherath Did you manage to find a resolution to this issue?  We have just starting encountering the same issue.  I have updated the knownhost file, but now am not able to upload it...the logs which I have requested from IFS all indicate “Fatal error in timer iREADER:Areader_name]] count=1495 delay=600000” and I have not been able to get beyond this.

@sherath 
Please check if the correct DNS are entered in the main_config.json file.
Once you have above in place, you must set it at the pod level by running this command from the management server.
 .\main.ps1 -resource "SETK8SDNS"

This was helpful in my case.
Hope this help!
 

Set CoreDNS DNS server

By default, the DNS used by Kubernetes points to 8.8.8.8 8.8.4.4. This script is only needed if an internal DNS is needed (e.g. if public DNS servers are blocked or if internal hosts need to be resolved by the pods)

Edit the #Dns# tag in config\main_config.json and set it to the corporate DNS. If using a list of DNS servers, use spaces as separators.

ps> .\main.ps1 -resource "SETK8SDNS"

Hi @Sylvan ,

The issue was resolved by removing the existing sftp reder, sender and creating a new sftp reader, sender instance on the application.

We also took a note to export the tables containing the sftp reader, sender information on the database before performing a clone.

Just an update (in case it helps anyone else)...in the end, I was able to upload our updated knownhost file successfully after adding an extension of .txt.  The confusion was that the file uploaded withOUT the extension in our 23r1su9 environments (we are in the middle of upgrading)...but for some reason 22r1su10 requires it.  

Reply


Terms & ConditionsCookie settings