Running xo-cli command returns Unhandled Error
-
Can you provide just the output when doing the command directly? This will be easier to spot the problem
-
@olivierlambert That is the output, it times out after a few minutes then spits that out
-
oh okay, it's a bit weird, I don't remember ever seeing this Opinion @julien-f ?
-
@olivierlambert Never heard of
invalid code lengths set
.Also, it's strange that this command is not working but others areβ¦ Maybe it's related to the size of the responseβ¦
You can try to use the REST API:
xo-cli rest get -o records.ndjson plugins/audit/records fields=data,event,subject,time,id ndjson
-
@julien-f It finished with a records.ndjson file of 510.31 MiB. There's been the max 10,000 audit records since I've started, so I can't imagine the size is part of the issue. And yes, the REST API would work, but it was a bit more elegant to have the json loaded in memory rather than get the file first, then load it. Not that it makes a huge difference.
However, now that I'm taking a look at it, all of the "method" fields show "host.isPubKeyTooShort". I'll have to sift through the data to see if everything I need from the records are there.
-
After some playing around,
xo-cli rest --json get -o records.json plugins/audit/records fields=data,event,subject,time,id
actually got the records and put them in JSON format. However, I don't need all the records, is there a way to match the 'method' to 'vm.snapshot'? That way I'm not downloading and parsing a 500ish MiB file every time ? I've tried addingmethod=vm.snapshot
andevent=vm.snapshot
, but neither worked (I'm probably putting it in the wrong spot) -
@nick-lloyd Yes, you can filter collection using the same syntax of XO's Home page as explained in the REST API documentation:
xo-cli rest get plugins/audit/records filter=data:method:vm.snapshot
-
@julien-f Thank you for the info! After some playing around and some outside help, this is what worked:
xo-cli rest --json get -o records.json plugins/audit/records fields=data,event,subject,time,id filter=data:method:vm.snapshot
. However, anytime I run it, it takes about 4 minutes for that command to run (albeit now only downloading about 20 KiB). And with this python, it's going to loop through each XO(A) instance, so some guidance on how to lower this time (or troubleshoot) would be appreciated!EDIT: The downloading part only takes a second or two, but waiting for the command to execute takes 3-4 minutes
-
@nick-lloyd How long does it take without the use of the filter?
-
@Danp To execute the command, it's almost instant. To download the file, the same 4ish minutes. I'd also like to note that despite holding a similar 10,000 records, the file becomes significantly longer each run when running the unfiltered command (about 5-10 MiB larger, currently at 610 MiB).
I guess I have three questions now:
- Is there any way to make my filter "more efficient"?
- When executing the command with and without the filter, is it getting audit records that have since been purged from XO(A)? If so, that's great news for me. Just means that the command takes more time, but I don't have to worry about getting and filtering those records separately.
- As @jgrafton just brought up to me: Is it possible to store the username of the user that made the snapshot in the VM snapshot object? We're basically combining the above audit command and joining it on the snapshot uuid of
xo-cli list-objects type=VM-snapshot
in order to get username of the person who did the snapshot.
Before last week,
xo-cli audit.getRecords --json
took maybe 30-60 seconds to run. It's weird that it just started in the middle of the week unprovoked. -
@nick-lloyd I'm not sure that I understand how the file could be getting larger each time. Are you removing the file between runs?
Is there any way to make my filter "more efficient"?
Not AFAIK.
When executing the command with and without the filter, is it getting audit records that have since been purged from XO(A)?
See above answer.
Is it possible to store the username of the user that made the snapshot in the VM snapshot object?
Same answer. But you can user ID can be found in the VM snapshot object and you can join that with the user list to identify the user.
-
-
The file is getting removed every time, that's why I was questioning the behavior of the command (whether it is grabbing all records or cached records).
-
We can do that, but if the user is deleted, that user entry would be gone.
-