[Jason Russell]

That likely won’t help here as we’re not on segregated networks with no firewall between us. Do you know what the error was? Ours is saying we’re accessing the socket in a forbidden way. Sadly they’re dragging their feet on this.

[Jason Russell]

The uuencode and base64 packages never worked right for me. As I noted, the binary encode/decode worked flawlessly without all of the additional stuff once I replaced the \r\n with just the \n (and replacing the rest of the characters). Not sure if a string map would have been more functional there instead of splitting and rejoining, but it’s functional which is what is most important.

If we do another muse upgrade, I may see if they’ll switch to base64. This was more of an in-place replacement when we were integrating Cloverleaf. Working with the UUencoding was exhausting.

[Jason Russell]

I agree that you should avoid dealing with binary PDFs. TCL does have a builtin protocol to do that vs running it via exec:

set pdf [<get PDF however>]

set b64 [binary encode base64 $pdf]

This is also a bit more portable between environments.

[Jason Russell]

With all of that said above, these are the things I’ve tried, and none seem to work. This is called from a master site alerts window, calling a TCL proc. It doesn’t throw errors like it did before, but it just doens’t seem to do anything. No engine logs in any of the sites that I could tell.

set callPath “$::env(HCIROOT)/bin”
#exec “$callPath/hcisetenv -site $::site; $callPath/hcienginerun -p $process”
#exec $::env(HCIROOT)/kshlib/setroot
#exec $::env(HCIROOT)/kshlib/setsite $::site
#exec $::env(HCIROOT)/bin/hcienginerun -p $process
set setroot “$::env(HCIROOT)/kshlib/setroot”
set setsite “$::env(HCIROOT)/kshlib/setsite $::site”
set engRun “$::env(HCIROOT)/bin/hcienginerun -p $process”
exec “$setroot; $setsite; $engRun”
#setsite $::site
#hcienginerun -p $process

[Jason Russell]

Without knowing anything about SNOW I would assume it would depend on any APIs or other ways to get data into the software. There’s unlikely a native way to do it form Cloverleaf, you’d likely need to write a script to format data in whichever way SNOW will take it to create a ticket. We use SolarWinds here for our ticketing system and I’d just jump to sending an email, it’s likely the easiest way.

[Jason Russell]

Was a bit rushed yesterday and just now looked at your script, and it’s a KSH script (which is fine) but we were doing this via TCL through the alerts section, which is probably why some of these scripts are not working. Still interesting, going to try and change tactics a bit.

 

[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 4 weeks ago by Jason Russell.
• This reply was modified 4 weeks ago by Jason Russell.
• This reply was modified 4 weeks 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).

[Author]

Replies