Make install script compatible with openSUSE

[yubiuser]

What does this PR aim to accomplish?:

This PRs combines and supersedes #5001 and #5027.
It allows installation of Pi-hole on openSUSE Tumbleweed and Leap(15) and adds the necessary tests.

Link documentation PRs if any are needed to support this PR:

No documentation changes needed. openSUSE is not officially supported, but now compatible with Pi-hole. Uses will still need to bypass OS check during installation

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[yubiuser]

The last commit is necessary for the test to pass (permissions for `/etc/lighttpd/lighttpd.conf on openSUSE prevent 'other' from reading it). I thought it might be a good solo-PR to always set the permissions so I created #5038 which can be merged separately if wanted.

[PromoFaux]

It allows installation of Pi-hole on openSUSE Tumbleweed and Leap(15) and adds the necessary tests.

No documentation changes needed. openSUSE is not officially supported, but now compatible with Pi-hole. Uses will still need to bypass OS check during installation

Some questions and thoughts:

If we don't officially support it, why then are we adding in special handling and tests for this OS? If we're adding in special handling and tests for this OS, why don't we officially support it?

Why are we also including tests against the rolling release version (and by extension accepting version=any)? We don't do this for Debian Testing...

I would like to hear from @dschaper and @DL6ER on this, too.

In theory I have nothing against increasing compatibility - but we either support it or we don't. This reads like some strange in-between land :)

[DL6ER]

Sorry, I have been so busy with FTL development in every free minute that I haven't actually looked at the other repos recently - so I missed this one, too. Having tests doesn't feel right to me. I see why we should have them (because all features should be tested as much as is maintainable) but I'm more thinking about the consequences of "what will happen when it breaks". This kind of forces us to fix SUSE when it breaks. Or we'll have to live with red crosses on all commits from this point in time on. Or we have to rip out the code we added here and remove the tests. I guess you see my line of argumentation.

TL;DR: Tests forcing us to fix things make it a supported OS. A supported OS that nobody is running at home (or is familiar enough to quickly fix quirks) is not really a supported OS. Sounds very much like an insoluble problem.

[yubiuser]

Why are we also including tests against the rolling release version (and by extension accepting version=any)?

Because the original author (coogor) targeted tumbleweed in the first place. I included any to have a way to "allow any version" (set by the resp. DNS TXT record) because the version set in /etc/os-release will change very frequently even in the images we pull for the tests. As this is a rolling release distro it didn't made much sense to set a fixed version here.

__

TL;DR: Tests forcing us to fix things make it a supported OS. A supported OS that nobody is running at home (or is familiar enough to quickly fix quirks) is not really a supported OS. Sounds very much like an insoluble problem.

When I saw the contribution from coogor I thought that with only a small change to basic-install.sh we could offer to run Pi-hole on a so far completely new distro. But I also needed a way to make sure it will really run on that distro - so I added the tests. I know it's a strange in-between-land. We could also drop the test and just make the installer compatible and in case it's breaking we wait for issues/PRs from users actually running openSUSE...

[rdwebdesign]

I'm not against supporting a new OS, but I'm against the "in-between-land" state. We support, or we don't officially support.

I think removing the tests and use the strategy "fix when it's broken" (only if it's possible to fix) is the way to go, since there are no developers using this OS.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved.

[dschaper]

It is kind of a strange situation.

I don't mind the tests directly, it's nice to know if things work on other operating systems. However, what do we do when SUSE is the only broken OS? Do we set the SUSE tests to be non-required? How do we determine when to allow the test to fail and when to require the PR code to be changed for SUSE.

I don't like the idea of testing against, or even supporting, a rolling release. Way too many variables to account for.

I guess the determining factor for me is 3. I am willing to help maintain this change if there are issues with it later. If you are willing to make sure that the changes in this PR are going to be maintained by you then I'm okay with it.

[yubiuser]

I removed Tumbleweed tests after internal discussion.

[coogor]

I removed Tumbleweed tests after internal discussion.

So only testing for Leap or are you intending to bin support for openSUSE (not SUSE) completely?

[yubiuser]

We decided that we don't have the resources to "support" a rolling distribution which can break anytime without us making changes to Pi-hole. Therefore we won't implement tests for Tumbleweed. The code itself should still work. Tests for Leap are also still part of this PR.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Existing merge conflicts have not been addressed. This PR is considered abandoned.