Because it allows you to manage multiple concurrent services nicely. You have nice logging, you can check the status of each service, you can can specify dependencies, you can even applying runtime hardening for those services too.
On top of that, if paths and timers work, it will also be much better as you now will be able to configure triggers for certain task much more properly than using the likes of cronjobs or inotify.
rc.local is also run by a systemd service on normal distros after SysV init got axed, but it is bad enough that distros eventually deprecated it in favor of proper setups with systemd.
damn didn’t know that hope rc.local stays in qubes forever. So many guides really on it (most importantly qubes-vpn-support). I don’t think it’s that problematic on qubes
Because it allows you to manage multiple concurrent services nicely. You have nice logging, you can check the status of each service, you can even applying runtime hardening for those services too.
This is a poorer way of doing the same thing. Essentially, you are using a systemd service with its own dependency and start condition to sequentially launch other services, rather than letting systemd do dependency resolution of the services and start them up itself.
This is a poorer way of doing the same thing. Essentially, you are using a systemd service with its own dependency and start condition to sequentially launch other services, rather than letting systemd do dependency resolution of the services and start them up itself.
And what this the actual problem with that, i.e. what are the negative effects for the user? (considering the actual dependency of the unit running rc.local)
I don’t think there currently is any issue regarding this (in Qubes). But I would agree that avoiding rc.local is the better way forward considering it’s deprecated
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.
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.
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:
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 beforequbes-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:
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.
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.
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:
Qubes OS is not a Linux distro
systemd is controversial
/rw/config/rc.local is not deprecated in Qubes OS
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.
