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