0

I have to use a third party software which officially supports RHEL, SuSE (SLE[DS]) and a certain Ubuntu LTS release.

Unfortunately, I use Debian on all my systems.

If I run the installer script of the software, it exits with an error message ("Distribution not supported") and doesn't install.

The installation download comes with a .deb package which is actually meant for Ubuntu. This .deb file is installed by the installer script if and only if /etc/os-release contains a Ubuntu version (simple String check). But the good news is: You can just find the name of the .deb file and install it manually using dpkg -i on Debian and the installed software works just perfectly. :)

There is just one thing I'm not satisfied with: The automated updates feature of the software uses the above mentioned installer script which doesn't like Debian. So I don't get unattended upgrades for this application: The update process successfully downloads new versions including the .deb file but than launches the unwilling installer script instead of just installing the .deb file. The installer exits with error. Update failed. :( (I don't know why the vendor doesn't simply provide a URL for /etc/apt/sources.list.d and instead made this creepy custom update mechanism.)

I have to manually download a new version, extract the *.deb file and reinstall that.

Do you have some ideas or suggestions what I could do about that?

I could simply edit the text file /etc/os-release to say "Ubuntu" instead of "Debian". Then the problem would be gone. But will that have side effects on the system, e.g. trouble with apt-get update && apt-get upgrade?

Or can I "mount" a fake /etc/os-release file for a certain systemd service unit? So that only this service thinks it runs on Ubuntu instead of Debian? Maybe something like a chroot? But wouldn't I have to manually keep the entire system copy up-to-date in the chroot directory?

Improve this question
4
  • 4
    What is the software? Is there a link to it?
    – Nasir Riley
    Commented Mar 12 at 21:37
  • 2
    sounds a lot like a use case of a simple linux container, done
    – Marcus Müller
    Commented Mar 12 at 21:54
  • This ^^^ If open-source compile it for your system; if commercial closed-source then likely there are reason for it being packaged for those distros only. Either way this looks like a X-Y problem. And, as above, you can use a container.
    – ChanganAuto
    Commented Mar 12 at 21:55
  • If it's commercial software be (very) aware that you may invalidate any support agreement you have with the provider if you install and run on an unsupported system. IME different vendors vary - some refuse point blank to even consider helping if you're on an unsupported system, others will try to help you up to a "reasonable" point. In such situations it fast gets to the point that it's worth running an Ubuntu system (or whatever) in your estate just to keep the software support and maintenance
    – Chris Davies
    Commented Mar 13 at 12:59

1 Answer 1

Reset to default
6

Or can I "mount" a fake /etc/os-release file for a certain systemd service unit?

This is exactly what systemd's BindPaths and BindReadOnlyPaths options are for (docs):

BindPaths=, BindReadOnlyPaths=

Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place in the unit's view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible in the host's mount table. This option expects a whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional. If only a source path is specified the source and destination is taken to be the same. The option string may be either "rbind" or "norbind" for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string must be omitted too. Each bind mount definition may be prefixed with "-", in which case it will be ignored when its source path does not exist.

BindPaths= creates regular writable bind mounts (unless the source file system mount is already marked read-only), while BindReadOnlyPaths= creates read-only bind mounts. These settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is used.

Consider a simple service that runs a web server pointing at the /etc directory:

[Service]
Type=exec
ExecStart=/usr/sbin/darkhttpd /etc --port 8080

If I run this service and visit http://localhost:8080/os-release, I will see the file content from my Fedora host:

$ curl -s http://localhost:8080/os-release
NAME="Fedora Linux"
VERSION="39 (Workstation Edition)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
...

I can modify the service to bind mount a fake os-release file onto that location. First, I create /tmp/fake-osrelease with the following content:

NAME="I reall am Ubuntu"

And then I add a BindReadOnlyPaths option to my service unit:

[Service]
Type=exec
ExecStart=/usr/sbin/darkhttpd /etc --port 8080
BindReadOnlyPaths=/tmp/fake-osrelease:/etc/os-release

Now if I reload system and restart the service:

systemctl daemon-reload
systemctl restart fakeosrelease.service

I will see the fake content when I examine the os-release file:

$ curl -s http://localhost:8080/os-release
NAME="I am really Ubuntu"

This change only effects the service itself; if I were to to cat /etc/os-release I would still see the original content.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .