Mullvad VPN setup guide

Apart from a random forum user, where does it say rc.local is deprecated?

/rw/config/rc.local - script runs at VM startup. Good place to change some service settings, replace config files with its copy stored in /rw/config
Config files | Qubes OS

/etc/rc.local and /rw/config/rc.local is not the same thing.

From the look of it, it is running after network-pre.target, qubes-mount-dirs.service, qubes-network.service, and qubes-firewall.service.

The qubes-mount-dirs.service stuff is unavoidable, but it sill would be nice to be able to run other stuff before the other 3. qubes-mount-dirs runs as early in the boot process as it possibly can, before other mount points like rw.mount, home.mount and even the gui-agent, so if it is possible to launch custom services this early it will be nicer.

Apart from a random forum user, where does it say rc.local is deprecated?

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

/etc/rc.local and /rw/config/rc.local is not the same thing.

Except its functionally is the same and the implementation is practically the same - execute /etc/rc.local late in the boot process

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

https://suckless.org/sucks/systemd/

Except its functionally is the same and the implementation is practically the same - execute /etc/rc.local late in the boot process

From the look of it, it is running after network-pre.target, qubes-mount-dirs.service, qubes-network.service, and qubes-firewall.service.

If you want to run something before network.target, put it in /rw/config/qubes-firewall.d. See the doc @renehoj linked to.

The qubes-mount-dirs.service stuff is unavoidable, but it sill would be nice to be able to run other stuff before the other 3. qubes-mount-dirs runs as early in the boot process as it possibly can, before other mount points like rw.mount, home.mount and even the gui-agent, so if it is possible to launch custom services this early it will be nicer.

You can suggest it on GitHub and post a link to it here.

software that sucks less | suckless.org software that sucks less

I don’t take Suckless seriously, and I don’t think anyone should. Systemd is how you have nice, consistent system management in the Linux ecosystem, and how you enforce a lot of hardening. There is a reason why most major Linux distributions use it, and it’s more than just “hurr hurr evil Red Hat is taking over”.

Their sinit sucks and I doubt any serious sysadmin will use them in production. It’s just SysV init but worse. They have no concepts of dependencies handling, no concepts of run levels or targets, no self healing, no overview of the system, and certainly no concept of runtime hardening. If there is anything that is a “menace” and “disease” as they say in the Linux world, it would be their ideology and projects.

You can suggest it on GitHub and post a link to it here.

I will do it later after I have worked out the actual implementation.

It is not that simplistic like you make it out to be either. I am making a new guide on how to set up Lokinet on Qubes right now and I just ran into a perfect example of why using the /rw/config/rc.local file is not proper.

For context:

  • Lokinet wants DNS to be managed by resolvconf.
  • resolvconf works by symlinking /run/resolvconf/resolv.conf /etc/resolv.conf
  • qubes-network-uplink overrides this by adding its own /etc/resolv.conf.

So what is the solution to this? We need to run the following after qubes-network-uplink.service finishes starting up:

rm -rf /etc/resolv.conf
ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

With a systemd service, this is very simple to do: Just use After=qubes-network-uplink.service as a start condition for the service that will run those commands. Nice, simple, easy and with guarantees that it will only be started AFTER qubes-network-uplink.service has started successfully.

What about the rc.local file?

It is started by qubes-post-misc.service, which has the following conditions:
After=network-pre.target
After=qubes-mount-dirs.service
After=qubes-network.service
After=qubes-firewall.service

These start conditions do not guarantee that the commands will be executed qubes-network-uplink.service has started. In fact, if you were to make a systemd service with these conditions, it will run before qubes-network-uplink.service, and have its resolv.conf overwritten by qubes-network-uplink.service.

The only reason this suggestion with rc.local even works is that qubes-post-misc.service also invokes:

. /usr/lib/qubes/functions

/usr/lib/qubes/update-proxy-configs

These happen to take long enough to run that the commands in rc.local get executed after qubes-network-uplink.service. It’s just pure luck.

This is not how proper dependency resolution works on any system that’s supposed to be reliable. You should not be engineering something that relies on luck like this to run. Stuff like this are why rc.local is deprecated almost everywhere.

There is a reason why most [1] major [2] Linux distributions use it, and it’s more than just “hurr hurr evil Red Hat is taking over”.

[1] Argumentum ad populum - Wikipedia
[2] Argument from authority - Wikipedia

You can suggest it on GitHub and post a link to it here.

I will do it later after I have worked out the actual implementation.

Looking forward to reading what devs would answer.

[1] Argumentum ad populum - Wikipedia
[2] Argument from authority - Wikipedia

What is this supposed to mean? I literally showed you 1 very easy technical example of how systemd dependency resolution is better than the whole rc.local business or whatever “suckless” does. There are countless examples of stuff similar to this.

I do find it particularly ridiculous that instead of replying with technical arguments, all you have done is linking “suckless” and irrelevant Wikipedia pages.

red hat bad

Smh

What is this supposed to mean?

That these are fallacies, i.e. non-arguments.

I literally showed you 1 very easy technical example of how systemd dependency resolution is better than the whole rc.local business or whatever “suckless” does. There are countless examples of stuff similar to this.

I do find it particularly ridiculous that instead of replying with technical arguments, all you have done is linking “suckless” and irrelevant Wikipedia pages.

They are relevant to your replies and a short way to remind that:

  1. Qubes OS is not a Linux distro
  2. systemd is controversial
  3. /rw/config/rc.local is not deprecated in Qubes OS
  4. In the end, what matters is what Qubes’ devs would say

Those are facts.

Here is one more: It should be possible to use a non-systemd distro as a template. /rw/config/rc.local is a way to have that.

  1. Doesn’t matter, the templates are Linux and so is dom0. Services are run by Linux qubes, not the hypervisor. This statement is completely useless and doesn’t even apply to the discussion at hand.
  2. Doesn’t matter, most of the anti systemd people don’t know what they are talking about. Just because there are a group of angry people saying ridiculous stuff like the Suckless group or Devuan doesn’t mean that you bastardize your own system design to appeal to them.
  3. Doesn’t mean it is the proper way to do things, as demonstrated above.

And no, this is not how a system should be designed. If you care so much about being inclusive and providing freedom, the proper solution is to engineer the guest agent to cater to each operating system’s way of handling services. If Qubes were to be treated like a Hypervisor, it should work with everything, Windows, macOS, the BSDs, etc… not just those anti-systemd-for-no-sensible-reason distros.

If Qubes were to be treated like a Hypervisor, it should work with everything

Can you do it?

What are you even talking about at this point? That is just to show how the whole “hurr hurr Qubes is not a Linux distro” argument is ridiculous when you are trying to schedule a service inside of a systemd Linux system.

At this point I think we should just stop talking, because you clearly are insisting on not scheduling services properly cuz “hurr hurr Qubes has not decprecated rc.local yet its a fact!!!” and “systemd is controversial cuz the Suckess people say so!!!” regardless of how it is in reality. I have given you a concrete example of why it’s not proper, I don’t even know what else I can possibly give you at this point.

1 Like

When I asked:

That said, if you have arguments against it, have you reported it to GitHub?

you bombarded me with counter-questions:

It makes a mess out of managing services. How are you gonna run 2 concurrent services? How are you gonna manage logging for them? How are you going to their status? What about timers? Path? Runtime hardening?

which is not an answer.

Now you say:

What are you even talking about at this point?

I asked if you can do what you suggest. You are “answering” with a counter-question.

That is just to show how the whole “hurr hurr Qubes is not a Linux distro” argument is ridiculous when you are trying to schedule a service inside of a systemd Linux system.

I have never used the words “hurr hurr”. That is your way of discussing.

Qubes OS is not a Linux distro - that is a fact. It is a valid argument because you speak of “other distros”, implying that Qubes (not being one) should follow:

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

In that sense, your argument is not valid (and note: I am not saying ridiculous, I am explaining why it is invalid).

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd. Currently dom0 is too big and will hopefully be minimized one day. A minimal dom0 may use a different distro which will not use systemd, and that may be more appropriate from security perspective. I am not saying this will be so - that is up to devs to decide. I am just explaining there may exist valid reasons for other considerations, different from the desires of a single user, of multiple users, or of “most major” distros. In any case, templates are something different from the core and one should be able to use various OSs.

At this point I think we should just stop talking, because you clearly are insisting on not scheduling services properly cuz “hurr hurr Qubes has not decprecated rc.local yet its a fact!!!”

Where exactly did you see me insist on that?

and “systemd is controversial cuz the Suckess people say so!!!”.

This “cuz…” is another thing I have never said. Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it. That doesn’t mean I am against systemd (or for it), or “hurr hurr”. I am just saying it is controversial and that’s all. The “cuz…” is entirely your invention. I really don’t understand your desire to turn this into a fight.

I have given you a concrete example of why it’s not proper, I don’t even know what else I can possibly give you at this point.

A link to the GitHub issue, so we can all know what devs think about your suggestion. No need to get worked up.

This is literally just me talking about the general design of a hypervisor.

In that sense, your argument is not valid (and note: I am not saying ridiculous , I am explaining why it is invalid).

How is it invalid? The services are being scheduled on Linux, not Xen. If you were going to schedule service for Windows on Qubes, you have to cater to Windows’s way of doing things.

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd.

No it’s not. It is proper for it to depend on how the guest OS expects to schedule services inside of the guest OS. It’s a fact.

Currently dom0 is too big and will hopefully be minimized one day. A minimal dom0 may use a different distro which will not use systemd, and that may be more appropriate from security perspective.

It absolutely does not matter what dom0 uses. You are scheduling services inside of Linux guest with systemd, therefore inside of those guests you should be using systemd. The init system for dom0 has no baring on how service scheduling is done in a guest. This is a fact.

Removing systemd to use a bunch of half-baked tools which can’t do the job properly like Suckless are not reducing the attack surface. If you care about security, you should be keep systemd and add runtime hardening for the services. That is a much better way to do attack surface reduction. Which other init systems support that? Are they actually doing the job more properly than systemd?

Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it. That doesn’t mean I am against systemd (or for it), or “hurr hurr”. I am just saying it is controversial and that’s all. The “cuz…” is entirely your invention. I really don’t understand your desire to turn this into a fight.

They cannot back it up with real technical arguments and their systems are terrible. You linked a completely incoherent post which just craps on systemd for no reason and advocates for a terrible init system which doesn’t even understand basic dependency management, let alone more advanced stuff like runtime hardening.

Anyone can make up any amount of ridiculous things about a product and make it “controversial”. It doesn’t mean anything.

How is it invalid?

Because it is comparing oranges (“other distros”) to an apple (not a Linux distro). In that sense, your:

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

can be answered with the opposite, similarly invalid:

“Just because other distros have done X, doesn’t mean Qubes OS should do the same”.

The services are being scheduled on Linux, not Xen.

As discussed, there are non-systemd distros and those can be used as templates. If you mean that Qubes OS’s official templates that are systemd-based should implement a better scheduling of systemd units (with which, FWIW, I agree) - that is something entirely different from Qubes deprecating /rw/config/rc.local.

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd.

No it’s not. It is proper for it to depend on how the guest OS expects to schedule services inside of the guest OS.

What I said was about dom0.

It absolutely does not matter what dom0 uses. You are scheduling services inside of Linux guest with systemd, therefore inside of those guests you should be using systemd.

Yes, for the templates, it does not matter what dom0 uses. My note was in regards to systemd and Qubes OS design in general.

Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it.

They cannot back it up with real technical arguments and their systems are terrible.

You continue with slapping labels - OK, that is your way. I am nobody’s advocate. Facts are facts - there are such systems, there are technical experts developing them:

The only thing that matters for Qubes OS is what you can suggest and what the devs will say about it.

I do not think you are posting in good faith at this point. It looks more like you are just trying to derail the thread.

Because it is comparing oranges (“other distros”) to an apple (not a Linux distro).

No, I am comparing the behavior of normal distributions and their counterpart inside of a Qubes template. This is Linux to Linux comparison.

“Just because other distros have done X, doesn’t mean Qubes OS should do the same”.

Sure, except using rc.local on systemd systems is bad practice.

As discussed, there are non-systemd distros and those can be used as templates. If you mean that Qubes OS’s official templates that are systemd-based should implement a better scheduling of systemd units (with which, FWIW, I agree) - that is something entirely different from Qubes deprecating /rw/config/rc.local.

No. They should be using what those distros expect. You can’t just make a blanket designation that oh it should be rc.local. It doesn’t even work the same way with different init systems.

You continue with slapping labels - OK, that is your way. I am nobody’s advocate. Facts are facts - there are such systems, there are technical experts developing them:

Once again, you have linked something that says absolutely nothing in relation to the topic at hand. You just listed some Linux systems that do not use systemd for various technical reasons, then use it to make it a “fact” that systemd is somehow controversial.

  • GrapheneOS, DivestOS, etc are Android variants. They are using a whole different system design based on AOSP, so of course they aren’t using systemd. This is not because systemd is controversial or so bad that they avoid it at all cost. These are not your traditional Linux desktop stack. Oh, and what do you think the developers of these OSes use on their servers/workstations? systemd. I know this for a fact.
  • OpenWRT and DD-WRT are meant for extremely underpowered consumer routers, so they need to strip them down as much as possible. It has nothing to do with systemd being controversial.
  • Alpine is generally meant for OCI containers, so they don’t need systemd by virtue of the fact that the entrypoint of a container is just 1 binary that it’s supposed to run.
  • etc and etc

The only thing that matters for Qubes OS is what you can suggest and what the devs will say about it.

You keep bringing this up as if it is some kind of “gotcha” talking point. Even if Qubes keep rc.local because of legacy cruff, it doesn’t change the fact that it is legacy stuff and shouldn’t be used on systemd systems, as I have demonstrated above.

No matter how you engineer it (be it through the qubes service or the rc-local service systemd used to provide), it will never work properly. It’s is impossible to guarantee something to “run last” because such concept doesn’t exist in systemd. Also, using something that actually “runs last” to run stuff is not proper service scheduling either.

Hello, thank you for your work.
Could you please tell me how to solve the problems with the broken link in your script?

I run this script on my template to trim it down:

sudo dnf -y install 'https://divested.dev/rpm/fedora/divested-release-20231210-2.noarch.rpm'
[MIRROR] divested-release-20231210-2.noarch.rpm: Status code: 404 for https://divested.dev/rpm/fedora/divested-release-20231210-2.noarch.rpm

Thanks in advance for your help.

New setup hardened_malloc:

sudo dnf -y install 'https://gitlab.com/divested/divested-release/-/jobs/7046900191/artifacts/raw/build/noarch/divested-release-20240607-1.noarch.rpm'