[misc] Support rpm-ostree based distros in installation script

[M0Rf30]

Describe your changes

This add rpm-ostree binary detection in installation script and update kardianos/service module to lastest commits. It should close #1634

Latest commits of kardianos/service correctly detect and discriminate between /etc folders (init.d, systemd/system....)

[CLAassistant]

All committers have signed the CLA.

[jkrogers9862]

I am not sure I understand how this will fix #1634.
Does rpm-ostree call this install script when installing? This looks like it just simple fixes allowing install from the install script which was missing until now. The problem is that an error occurs during the post-trans scripts.

[M0Rf30]

I am not sure I understand how this will fix #1634. Does rpm-ostree call this install script when installing? This looks like it just simple fixes allowing install from the install script which was missing until now. The problem is that an error occurs during the post-trans scripts.

postinst fails on netbird service install for two main reasons:

• fails cause of non-updated service module (/etc/init.d is not something present on these distros).
• /usr/bin is not writable out of package manager installations

Recent commits of service module correctly return /etc/systemd/system path for systemd distros (that's the case of fedora atomic distros)

plus, I added rpm-ostree support to install script in order to leverage the rpm packages and repo instead of binary archive. As binary archive the executable should be copied under /usr/local/bin (or /var/localbin as mapped on these distros) that is the only PATH folder available in rw.

I opted for rpm-ostree support (binary under /usr/bin cause installation is handled by a privileged process)

[jkrogers9862]

Why was it not a universal problem? On Silverblue, I could still install until I tried to install packages libvirt and network-scripts. Given the nature of the problem and the proposed solution, I would have thought it would be a 100% failure.

How can I get a rpm to locally install and test this?

[M0Rf30]

Why was it not a universal problem? On Silverblue, I could still install until I tried to install packages libvirt and network-scripts. Given the nature of the problem and the proposed solution, I would have thought it would be a 100% failure.

How can I get a rpm to locally install and test this?

need to generate an rpm with goreleaser, check the documentation

[mlsmaycon]

@M0Rf30 we are using a forked version of github.com/kardianos/service; see

netbird/go.mod

Line 208 in 92a0092

replace github.com/kardianos/service => github.com/netbirdio/service v0.0.0-20230215170314-b923b89432b0

Can you make this PR only about adding rpm-ostree, or is the module update a requirement for it? if so, we will update the fork and update the module in a separate PR first.

[jkrogers9862]

@M0Rf30 we are using a forked version of github.com/kardianos/service; see

netbird/go.mod

Line 208 in 92a0092

replace github.com/kardianos/service => github.com/netbirdio/service v0.0.0-20230215170314-b923b89432b0

Can you make this PR only about adding rpm-ostree, or is the module update a requirement for it? if so, we will update the fork and update the module in a separate PR first.

From my understanding the module update is what this Pull Request is actually for to fix: #1634. I believe the author decided to also update the install script in addition as it was missing. The problem is that on Fedora Atomic-Based Operating Systems, netbird fails to be layered when certain packages are also layered. On Silverblue variants it fails to install when libvirt and network-scripts is layered and on Fedora IoT and CoreOS, it can't be layered period because parts of those packages are included in the base immutable-images which leaves the Docker variant as the only alternative on those systems.

It seems some updates were made to the kardiano/service which included fixes that solve the issue relating to the issue of layering on these Systems. So if something is to be removed from this pull it should be the update to the install script.

[mlsmaycon]

@M0Rf30 we are using a forked version of github.com/kardianos/service; see

netbird/go.mod

Line 208 in 92a0092

replace github.com/kardianos/service => github.com/netbirdio/service v0.0.0-20230215170314-b923b89432b0

Can you make this PR only about adding rpm-ostree, or is the module update a requirement for it? if so, we will update the fork and update the module in a separate PR first.

From my understanding the module update is what this Pull Request is actually for to fix: #1634. I believe the author decided to also update the install script in addition as it was missing. The problem is that on Fedora Atomic-Based Operating Systems, netbird fails to be layered when certain packages are also layered. On Silverblue variants it fails to install when libvirt and network-scripts is layered and on Fedora IoT and CoreOS, it can't be layered period because parts of those packages are included in the base immutable-images which leaves the Docker variant as the only alternative on those systems.

It seems some updates were made to the kardiano/service which included fixes that solve the issue relating to the issue of installing. So if something is to be removed from this pull it should be the update to the install script.

I see, in this case it is better for us to upgrade the fork and update the go.mod and go.sum.

I will prepare the PR in a few hours

[M0Rf30]

I will prepare the PR in a few hours

Already done here in the same time I've opened this

See
netbirdio/service#2

After the service PR merge I expect only a bump of
v0.0.0-20230215170314-b923b89432b0 in netbird go.mod

[bcmmbaga]

@M0Rf30 The service PR is already merged can you bump the version in go.mod?

[M0Rf30]

@M0Rf30 The service PR is already merged can you bump the version in go.mod?

Done

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud