[Jason Russell]

I’m going to piggyback off this conversation, how do you guys set your retention? Cloverleaf only wants to do file sized based cycling. If I have to, I will write a shell script to loop through sites, but this is one of my gripes with Cloverleaf is it’s difficult to do things from a global level. This requires ‘switching’ to each site, then running the command on each thread to cycle the logs. At that time the automatic removal can remove files older than whatever time frame.

So the short question: How are you cycling the databases so they will automatically be removed?

[Jason Russell]

Is this happening on more than one site? This should be pretty site-specific. There’s a lot of points user entry. Make sure there’s no errant opening or closing braces in your upoc args. You shouldn’t have ANY opening or closing braces. . Can you post the netconfig? Someone can probably quickly see what is wrong.

[Jason Russell]

I missed that. You’re correct:

set myklst [msgmetaget $mh DRIVERCTL]
keylget myklst FILENAME fileName

Pretty sure I ganked that from another script before I understood keylget.

[Jason Russell]

So I started up the audit log, and the only thing you can see is a user is granted permission on hcierrordb. It doesn’t show any commands run beyond that. There may be more logs I’m unaware of, but that’s the closest I found.

[Jason Russell]

I don’t know that there is a log of these items. Audit log doesn’t seem to cover this (I could be wrong, ours is off). You’d have to have the audit log turned on in the first place. If your log is on, you can run hciauditlog from the command line in Linux, and in windows it’s supposed to be under start > tools.

I’m not sure how detailed the logs get. I might turn ours on just to see.

[Jason Russell]

I don’t see anything particularly wrong with the code. How is it not working? What is the echo of the $base going in and the $newbase coming out?

[Jason Russell]

The biggest issue I’m having, and it’s actually coming up in another script is it doens’t seem the setsite/setroot is actually doing anything. We have a global command line script via TCL and I’m doing some connection checking in another site, and the setsite/root doesn’t seem to work at all. As in my above example, I’m trying to change to a site to attempt to restart the engine, but that isn’t working. No logs in monitorD logs, alert logs, process logs. Just nothing. Echoing in the script doesnt’ return much either.

[Jason Russell]

Yeah, CL matches pretty well (we don’t use the pdl-tcp, just the standard tcp connection). It’s connecting, but no ack, so I’m still thinking it’s an Epic issue they’re having.

[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.

 

[Author]

Replies