Node_exporter: Provide pre-built binaries for FreeBSD

[hayalci]

In the download page, all components except node_exporter is provided for 7 architectures. Is node_exporter just missed from the builds, or is there an issue with the architectures which are not provided?

[brian-brazil]

Taking FreeBSD as an example, due to the modules needing to use FreeBSD-specifc syscalls we'd require FreeBSD header files that can only be found only FreeBSD. As we're cross-compiling from Linux, we thus can't compile it.

There was talk of someone getting node exporter into FreeBSD ports, which would be the best way to solve this.

@sdurrheimer

[sdurrheimer]

@hayalci Most of the time, if a architecture is not provided as a pre-compiled binary, it's because we were not able to crossbuild it from Linux.

You can try to crossbuild it manually to see the error encountered by doing (requires docker and promu):

# Example with the freebsd/amd64 platform
promu crossbuild -p 'freebsd/amd64'

[jevonearth]

I have created a FreeBSD port, and it is currently submitted to the FreeBSD bug tracker. Hopefully it will get included in the next week or so.

Any feedback from the prometheus team on the port is very welcome too. I made the process run as nobody and listens on :9100.

Cheers,
Jev

[brian-brazil]

That's good to hear. I'd suggest creating and passing in 1777 a directory for the textfile collector so that it works out of the box.

[jevonearth]

Great, I'll add that to the standard arguments tomorrow. Any opinion on the name/location if that directory? I put the data directory in /var/db/prometheus.

[brian-brazil]

I went with /var/lib/node_exporter/textfile_collector for my nightly debs.

I'd avoid prometheus in the name.

[SuperQ]

I recommend against 1777 dirs. On Linux I would recommend a prometheus system group and make the textfile dir group writable (0775). This would allow only group authorized tasks to submit data to the textfile dir.

[jevonearth]

I'm reluctant to add a prometheus user and group for the node_exporter. Adding a user for such a lightweight utility feels a bit heavy handed.

I do create a prometheus user/group for the net-mgmt/prometheus port that I also made, but I feel that's a different matter.

What do you think about setting mode to 1775 with a owner of root, and group of daemon. Then leave the rest up to the discretion of the system owner.

@brian-brazil /var/lib/ is a bit atypical in FreeBSD land, IMHO. I will use /var/tmp/node_exporter.

[brian-brazil]

I'm not sure what /var/tmp means on FreeBSD but as long as it's persisted between reboots that should be fine.

What do you think about setting mode to 1775 with a owner of root, and group of daemon. Then leave the rest up to the discretion of the system owner.

I can see things other than daemons wanting to write here. This really boils down to how the machine is presumed to be managed. On a multi-user machine allowing world write access would be a bad idea, however it'd be beneficial for a machine with a single owner.

[jevonearth]

/var/tmp certainly does persist across reboots. :)

I will go with /var/tmp/node_exporter with permissions of 1775, and with owner simply root:wheel. This forces the machine owner to make a choice when they go to use the feature. They can then change the permissions.

I feel this is better than leaving it open to all users, making it easy for the owner to overlook the matter.

[SuperQ]

That seems reasonable to me.

[jevonearth]

A quick update to those interested, the FreeBSD port request is still awaiting a FreeBSD committer (they seem to be backlogged). I'm prodding the FreeBSD ports list every week or so. Fingers crossed it should get committed soon.

[jevonearth]

FreeBSD port has now been committed. I think this Issue can now be closed. :)

https://svnweb.freebsd.org/ports?view=revision&revision=424002