[Jason Russell]

For some reason, the tcl script won’t call setsite. Maybe because of setroot. Let me modify and try that.

 

[Jason Russell]

Is there nothing else in your hcischeduler.log? I would expect since it’s not working it won’t have anything past the reboot date, but is there nothing in there that indicates an error?

[Jason Russell]

We’ve figured out most of the above questions. However, I’ve run into another interesting issue. We’re probably doing this ‘wrong’, but I’m trying to keep as much of the alerting in one place. We’re checking the status of the alerts via master (who can see all sites), however you can’t do any thing directly within the site from master (IE restarting the process). My intention was to run setsite and then hcienginerun. Initially the script couldn’t find setsite (not sure why), so I switched to a manual call to hcisetenv, but it’s now not finding hcienginerun (which is in the same folder, with same permissions): invalid command name “/opt/cloverleaf/cis2022.09/integrator/bin/hcienginerun”

-rwxrwxr-x. 1 hci staff 12969 Oct 11 2024 hcienginerun
-rwxrwxr-x. 1 hci staff 37153 Oct 11 2024 hcisetenv

I’m calling hcisetenv first and it seems to work just fine. Has anyone seen this?

[Jason Russell]

You need to check HCIROOT/server/hcischeduler/hcischeduler.log and see what it is failing on.

[Jason Russell]

That’s interesting. We’re on 8.10, looking to go to 2025, then jump to 10, we’ll have to double-verify we’re on a certified version when we go. However, we’ll be rebuilding from scratch when we go to 10 so it will be a full upgrade. Got some considerations with HA pairs, but that’s a different story. .

[Jason Russell]

Make sure you’re using @null not @Null (case sensitive).

[Jason Russell]

I edited too many times (the bbcode was trying to format the list command). here’s the code without the slashes:

set xlateOutVals [ list [clock format [clock scan [lindex $xlateInVals 0] -format %Y%m%d] -format “%Y-%m-%d”]]

[Jason Russell]

The variable you’re looking for is xlateInVals which is a list. If you are 100% certain you will always pass in a 8 digit date, you can use TCL’s clock command:

set xlateOutVals [ list [clock format [clock scan [lindex $xlateInVals 0] -format %Y%m%d\] -format “%Y-%m-%d”\]\]

From the inside out:

lindex gets the first item of the list passed in via xlateInVals

Clock scan will scan that in the format given (YYYYMMDD)

Clock format will format that scanned time in the format given (YYYY-MM-DD)

List recreates the list for xlateOutVals.

• This reply was modified 1 week, 1 day ago by Jason Russell.
• This reply was modified 1 week, 1 day ago by Jason Russell.
• This reply was modified 1 week, 1 day ago by Jason Russell.

[Jason Russell]

I’d be curious as to your experience on how far behind you stay in terms of Cloverleaf and server updates. We’re currently on RHEL 8.10 on CIS2022.09.03. We should have really updated to RHEL 9 but it was “too soon” when we started this migration to Cloverleaf. now that we’re done we’re looking at the upgrades, and I was looking at possibly staying one patch behind in Cloverleaf, and we’d stay current with RHEL.

We’re kind of stuck as our network security team is on top of a lot of stuff, and we’re already getting side-eyed with RHEL 8.0. This also applies to some of the cryptos that Cloverleaf uses (and tends to be behind on).

[Jason Russell]

There is an update in 2022.09.04 that helps deal with an issue with leading slashes and how Cloverleaf sends them via cURL. I’m not sure if that is the issue you’re experiencing (or if it’s a new or unknown server):

<td width=”600″>This enhancement introduces a configurable system variable that allows users to determine how the leading slash and special characters in SFTP absolute paths are encoded when connecting to SFTP servers. Previously, the system always encoded both the leading slash and special characters, which could cause compatibility issues with certain SFTP servers that do not support encoded leading slashes. With this update, users can select from four options:
0 (default): Both leading slash and special characters are encoded
1: Only special characters are encoded
2: Only the leading slash is encoded
3: Neither the leading slash nor special characters are encoded
This change provides greater flexibility and compatibility with a wider range of SFTP server implementations. No changes are required to existing configurations unless a different encoding behavior is desired. The new system variable can be set according to your environment’s requirements. No impact is expected on other programs, business classes, or extension processes. Infor has tested the new options to ensure correct path handling for all four settings. There are no dependencies or feature toggles associated with this enhancement.

[Jason Russell]

That’s probably what they’re running into. Do you have an SLG to point our TSes at? Do you remember what the error was or what (even vaguely) they had to do to fix?

Essentially we’re getting a connection, but no ack, and it’s not passing data to bridges like it should. They’ve got some errors on their side but the interconnect TS has never seen the error before.

[Jason Russell]

Just curious, is there any reason you all are sticking with 2022 vs moving to 2025?

[Jason Russell]

Yeah, we’ve completed all that, the interconnect guys have completed their setup, but it’s not working. Seems to be on the interconnect listener on Epic’s side. Their TS has found some errors. It’s our first incoming (to Epic) TCP/IP listener, and of course it’s giving us headaches. The only other one we do is a file-based and I’d love to move away from that.

[Jason Russell]

If you’re routing ACKs you probably don’t need any scripts on the replies, unless you’re doing work to them (unlikely).

[Jason Russell]

So a few things I have found:

If you have a 1:1 message:ack ratio (synchronous), you should have the ‘outbound only’ checkbox checked and everything routed via “route replies”. You should also have the “await replies” checkbox checked, with no proc (if you’re not specifically handling them) This treats all messages as a reply message. Anything that is NOT sent as a reply is thrown away and ignored.

If you do NOT have a 1:1 message:ack ratio (asynchronous) , you essentially do the opposite. You uncheck await replies and outbound only, and you route them via the “route message” tab (not the replies) and treat them as a data message. This ensures that all messages that are sent back in are routed.

I have a feeling with the way you’re describing it, it is as Jim says and you’re getting errant ACKS (delayed or whatnot), and you want option 1. That /should/ resolve the issue.

[Author]

Replies