@JasonWalker I am using this one to pull the creation date (creation time of data folder of client) of the BESData folder but am running into an issue on unix/linux devices. Any words of wisdom?
What kind of problem are you getting? What relevance is failing?
@JasonWalker āUndefinedā between carats. Trying to run this in an analysis. I have two properties for now, one is just the path and the other is the folder creation time. Any of the devices getting the āundefinedā error for the time actually do show a valid path with no issue.
Can you post the relevance clause you are trying?
(format ā{0}-{1}-{2}, {3}:{4}:{5}ā + year of item 1 of it as string + month of item 1 of it as two digits as string + day_of_month of item 1 of it as two digits as string + two digit hour of item 0 of it + two digit minute of item 0 of it + two digit second of item 0 of it) of (time (universal time zone) of it, date (universal time zone) of it) of (creation time of data folder of client)
Ah, I just looked it up, https://developer.bigfix.com/relevance/reference/filesystem-object.html#creation-time-of-filesystem-object-time
ācreation timeā only exists for Windows and Mac (and Iām guessing only for the old MacOS, not OSX). I donāt think Linux filesystems have a ācreation timeā attribute perhaps?
āModification timeā seems to exist on all platforms, give that a try and see if it retrieves what you need https://developer.bigfix.com/relevance/reference/filesystem-object.html#modification-time-of-filesystem-object-time
Oh, bummer. They do but I donāt think the inspector supports it. That would explain it. Thanks!
We do have āchange timeā if that helps? https://developer.bigfix.com/relevance/reference/filesystem-object.html#change-time-of-filesystem-object-time
Thanks Jason. Definitely handy but not what we need right now. We are trying detect when a bes client first registered. What we have found is that the minimum of subscribe times of sites doesnāt necessarily correlate to actual first report time.
? Minimum of subscribe timesā¦should? Unless thereās some kind of client reset happeningā¦
This might be a case for a one-time action to tag the machines. So you get a static value that is the āminimum of subscribe times of sitesā the first time the client is installed, that doesnāt get reset if the client is reinstalled or reset?
Not exists setting "ClientFirstTime" of client
Setting "ClientFirstTime"="{minimum of subscribe times of sites}" on "{parameter "action issue date" of action}"Iām not sure that āfirst report timeā is a thing that can be determined. ācreation time of data folderā maps, at best, to the time the client was installed. minimum of subscribe times of sites indicates the first data interaction with the server, so thatās pretty darn close.
1 Like
I created a property that I called BigFix Install Date that has this relevance
if (not unix of operating system) then (creation time of data folder of client) else (minimum of modification times of files of folder "actionsite" of data folder of client)
It may accomplish something close to what you are looking for @Viking
Yep, I did something very close to that but sadly, no joy for Linux,
Unfortunately, we have found that the minimum subscribe times of sites isnāt at all reliable in this use case. Thanks though. We are trying to determine what clients have come online in the last yearā¦ Easy for Windows and Mac but the Linux side is another matter.
I think we need to start over with you stating the problem instead of trying to hack at your solution.
You are saying that the āminimum of subscribe times of sitesā isnāt reliable - why not? What value are you getting and what value are you expecting? Is the āminimum of subscribe times of sitesā newer or older than what you expect?
Maybe we should be looking at the RPM package install date instead?
2 Likes
Fair and thanks again to everyone for their time. In September 2021, we had a platform upgrade fail that required a database restore. Unfortunately this caused us to have a problem on certain clients where they donāt report back relevant for various analyses that where in place before the restore depending on where they where in their evaluation cycle at the time. The fix is to clear the their BESData folders (outside of the client running obs). Then within about 24hrs, they come back with all of their data and relevance. Now because doing this is pretty stressful to the clients and the infrastructure, we are looking to mitigate the impact by targeting only the devices that have been around since before Sep 2021. So that is what we are trying to figure out.
What we noticed is the āFirst Report Time (Global Property)ā via āminimum of subscribe times of sitesā can be months (occasionally years) newer than the BESData folder create date (fast query).
Iām answering this old post for completeness.
This usually happens because the clients have a NEWER site version than the root server due to the restore. This is an issue that can resolve itself once the root serverās site version exceeds the client site version. If you want to clear clients that have this issue, then you should just be able to look at the versions of the sites the client has that exceed that of the root and then delete only those sites.