OpenBSD Support

[skarekrow]

Thanks for your work on this! Ideally I'd be having this run on my router (OpenBSD) as a standard user, which causes obvious failures since this relies on libcap for Linux :D

This PR is more a discussion point as I don't understand how to skip certain dependencies based on the GOOS received, but thought I'd show there's interest in running this outside of docker as an unprivileged user. I suspect since you can cross complie with many targets, this opens up the possibility of running on a lot of other UNIX-like systems (*BSD's come to mind)

This compiles fine and runs great on an OpenBSD host with this one dependency dropped however!

Ran using:

CF_API_TOKEN=YOUR-CLOUDFLARE-API-TOKEN DOMAINS=xxxx.org TZ=America/Chicago

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.49%. Comparing base (d599a88) to head (babfecc).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #733   +/-   ##
=======================================
  Coverage   88.49%   88.49%           
=======================================
  Files          48       48           
  Lines        1990     1990           
=======================================
  Hits         1761     1761           
  Misses        208      208           
  Partials       21       21           

Flag	Coverage Δ
unittests	88.49% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[favonia]

Thanks! See https://github.com/favonia/cloudflare-ddns/issues/728 for the plan to include a build that does exactly what you suggested. Ideally, it should be a build tag.

PS: any suggestion for the name of the alternative build that works for non-Linux (and apparently Linux containers)?

[skarekrow]

Hah, that's serendipitous! I think the tag name of nodrop might be good? I'm not sure since I think the 2 usecases are slightly different. On one hand, you want #728 for debugging issues like #707, but then on the other hand, we want this to be buildable on non-linux systems (like OpenBSD, macOS, etc).

I think maybe a good start is calling it something similar to your suggestions or mine for a build tag, and having a blurb in the README mentioning that alternative operating systems should try using the $BUILDTAG instead?

[favonia]

@skarekrow Yes, the two use cases differ, but they have the same solution. ;-) I want #728 to work for both reasons. Perhaps we can focus on portability and generality. I feel nodrop is a bit unclear... any other suggestions inspired by portability?

Or, maybe the original version should be called noroot?

BTW, you should have run go mod tidy :-)

[skarekrow]

@favonia haha i just didn't commit that after I noticed, I did now :D

I'm honestly not sure, maybe just calling it generic and the other build can be linux for now? Let's you down the road add things that specific OS may call for that linux or the normal generic don't require themselves?

EDIT: If we decide to use noroot it's a bit of a misnomer since it can indeed still be ran as root, it's just the dropping of privilege that doesn't occur. Maybe we can add a quick UID check to make sure it's not ran as root, but allow that nag to be overridden with a cli flag? Seems like a bit more engineering but I suppose it does prevent accidentally running it as root.

[favonia]

it can indeed still be ran as root, it's just the dropping of privilege that doesn't occur.

The DDNS updater will try very hard to change process UID and GID if it was 0 (usually the root). However, I do feel noroot might not be a good name. How about puid?

[skarekrow]

Well not without the droproot stuff we'd be dropping is what I mean. I'm not sure if puid is clear enough either :D perhaps just nocap?

[favonia]

@skarekrow I have been thinking about that but it gave me the feeling of "no limit (cap)" instead of "not manipulating capabilities" :shrug: (I don't have a good idea, either.)

[favonia]

How about setpuid for the current version that will take PUID?

[favonia]

For easier migration, I slightly prefer some UI warning the user that it is no longer taking PUID and PGID. However, this can be done later if you don't have time. The priority now is to make it a build tag instead of deleting the code.

[massijay]

What about nocapdrop or norootdrop?

[skarekrow]

@favonia don't worry, i haven't dropped. Just not a lot of time right now irl. I will say though, with a cursory glance at the go build flags, it doesn't seem like it will do what we want without making droproot a complete separate package? I'm pretty new to go packaging in general, so perhaps I'm overlooking something obvious here too.

EDIT: Are you against me including a sample rc file for OpenBSD users to use as well? I got it working nicely in my setup, it's quite simple!

[favonia]

Are you against me including a sample rc file for OpenBSD users to use as well? I got it working nicely in my setup, it's quite simple!

No, but please open a new issue or a new PR for that. :slightly_smiling_face:

[skarekrow]

@favonia OK all working locally here! The build fails when the tag is not supplied, as expected.

Ex:

• GOARCH=amd64 GOOS=openbsd go build ./cmd/ddns -> Fail (current behavior)
• GOARCH=amd64 GOOS=openbsd go build -tags nocapdrop ./cmd/ddns -> Builds and runds (new behavior)

[skarekrow]

I will say that I would prefer instead that we did this by OS, so if we ever need to extend specific support elsewhere. As in something like this:

checker_linux.go 
config_linux.go
drop_linux.go
drop_linux_test.go
drop_openbsd.go
drop_openbsd_test.go

Where we can then add a drop_freebsd for instance that may have some unique things it needs handled instead of a no-op. The downside is the default behavior would now need a build tag of linux for example. But as is, I stuck to what was discussed here and kept it simple.