any option to get information from one machine to other

You are probably doing

go run main.go

. You need to provide the socket path and query arguments, something like

go run main.go /var/osquery.em 'select * from time

.

Hi everyone, does anyone else has issues when registering an extension when restarting osquery? On a subset of our hosts, we see this log

"Refusing to register duplicate extension "

in osqueryd syslogs. It comes from ExtensionManagerInterface::registerExtension. The issue usually solves itself after a few retries, but not always.

Would it be possible to enable tagged version releases on https://github.com/osquery/osquery-go? Would be nice to be able to append something like

<http://github.com/osquery/osquery-go|github.com/osquery/osquery-go> v1.0.0

to my

go.mod

hrm. My gut sense is that adding the overhead of managing module releases for the little that changes isn’t worth it. Do you think that would be a substantial improvement over

v0.0.0-20220317165851-954ac78f381f

which is what it looks like today? And the

v0

pattern is pretty common for go modules.

(My general assumption is that if we ever break the API we’ll need to think harder. But api hasn’t changed yet)

I know with golang, version numbers can be used as a communication method for changes. For example, major version increases indicates breaking changes. Minor version increases indicates small updates. I personally prefer version numbers over

v0.0.0-20220317165851-954ac78f381f

. Also I like when the osquery project does releases, it includes the changes between releases which is nice. I understand if it’s a big lift for a small change but just something I wanted to ask about.

Lastly per the golang docs the

v0.0.0-*

notation can signal that a golang module is still in development. Is osquery-go still considered in development?

Seems reasonable to me to release a 1.0 of osquery-go. Maybe after @seph merges the mutex PR?

To be honest, I feel somewhat opposed, but I’m trying to keep an open mind.

I’m not sure I understand the problem it solves. You’ve said: • looks nicer • can signal not in development • provides a place to hang a changelog.

But I’m not sure those hold up in practice for a project that small, with that infrequent changes. When I work with similarly sized projects, I see 2 common patterns emerging. Either they cut a release on every change, or they never cut a release and anyone who cares just uses HEAD. And in those cases versioning adds overhead for negative value.

I’ve also read some reasonable criticism of go’s versioning choices. It only half stuck in my head, but there seems to be a lot of weirdness in the ecosystem about whether or not versions are git tags, or directories in source code, or ???.,

And for a project that sees a comment every month or two, that feels like a lot of overhead.

From where I sit (which I grant is not universal) the implicit pin-to-sha (almost TOFU style) is reasonable compromise. You get the version you started with. Upgrading works as long as we don’t change the API, and if we change the API then either you change the callers or don’t upgrade. Which is practically the same as you’d get with versions.

And as a side note, semver is not universal for go modules. several of them just use integers.

I’ve been revisiting the idea of mutexes, and I think they’re the wrong approach. They don’t have any kind of timeout behavior. Instead, I found some recommendations to use go channels as a form of interruptible mutex. PR up at https://github.com/osquery/osquery-go/pull/108

I propose we need more maintainers. https://github.com/osquery/foundation/issues/87

We’re thinking about adding otel traces. Feedback / buyin welcome. https://github.com/osquery/osquery-go/pull/110

Hi folks! @seph @Rebecca Mahany-Horton I can see Github CI automation that runs on every PR/push (

.github/workflows/go.yml

), any reason there's a failed CircleCI link in the repository README?

made a small update to the otel traces: https://github.com/osquery/osquery-go/pull/114

thanks for the review, Lucas!

👋 We stumbled upon what seems to be an issue with the long running queries and osquery Thrift RPC. We set the 1 minute timeout when we create Go client. The expensive query takes about 3 minutes to complete. So we get the context deadline exceeded, then for subsequent queries it either fails with context deadline, or

*osquery.ExtensionManagerQueryArgs.sql (1) field write error: i/o timeout

, or

query: out of order sequence response

As far as I remember the timeout at RPC level doesn’t stop the running query. Would appreciate some advice in case if somebody already saw that or have some suggestions how to handle this better. @seph maybe you have some insight?

I’ve put together the sample code that shows the problem, using the curl table and local http server (in order to emulate long running queries) https://github.com/aleksmaus/osqlong/blob/main/main.go README.md has more info and steps https://github.com/aleksmaus/osqlong/blob/main/README.md

@Aleksandr Maus Hrm. That’s a good point. I think we probably don’t have a way to kill a long running osquery query.

But, reviewing the locker code — https://github.com/osquery/osquery-go/blob/master/locker.go Does anything timeout a lock?

I saw distributed queries include a

messages

key we weren't currently extracting in osquery-go, so I've updated to include: https://github.com/osquery/osquery-go/pull/115

Hi folks! https://github.com/osquery/osquery-go/pull/117 fixes a nil dereference panic caused when calling

ExtensionManagerServer.Shutdown

more than once (I believe this was introduced here).