I'm certainly not a layperson, but systemd frequently confuses me.
I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates. Okay, makes sense, I need to use systemctl edit instead. But that opens a file that has everything commented out. Do I uncomment the [Unit] heading? What do I need to keep and where do I add my additions? I recall there being a comment at the start of this file, but unless I'm misremembering it doesn't answer that.
All I ask of it to do one thing - start something.service after other.service. yet it just refuses to order them this way. Why? I have no idea. I also have no idea where to start debugging a problem like this. There's a billion ways to try and do this after all: do I add Before=something to other.service? Do I add After=other to something.service? Both? Wants=something?
> I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates.
I don't think you're supposed to edit anything inside /usr, except perhaps /usr/local, but even that has a better alternative in the form of $HOME/.local, which is a well defined standard at this point.
Maybe I'm unaware or mistaken but if you're editing anything inside /usr as a normal user, you're either using Linux wrong or doing something unexpected or unusual. This is why requests to make GUI file explorers have root escalation capabilities sound absurd to me. I can't think of a reason why one would need root access when using a file manager, especially a GUI file manager.
Even in that case, if you're manually editing anything inside /usr either by being root or by using sudo, you're doing something wrong or unexpected.
Anything inside /usr should only ever be modified by the package manager, not by the root user, or any other user for that matter.
If you want to make system wide changes, make them in /etc. If you want to make user specific changes, make them in $HOME/.config, $HOME/.local. Your package manager should never overwrite anything in /etc or $HOME. If it does, it's a bug.
So here's the thing, right. You are correct. And I agree.
I'll admit something; I forgot where the service files were (I don't use systemd often). So, in my unix wisdom I used `find` to find the files ending with 'service'. The only ones that came up were in /usr/lib
You're right, I'd typically never edit files in /usr. But I wasn't sure how else to do it at the time.
This doesn't happen. The package manager installs the new configuration under a different name so that you do not lose your changes and can merge them easily.
what they are saying is that they edited the file in /usr/lib , which definitely would get overwritten. You're supossed to copy it into /etc/systemd/ for the appropriate service type.
It's like saying a car is too complicated because I can't just swap the engine out without any prior knowledge. It's not designed for the average guy to be able to do that.
systemd is not some product meant for the average Joe, it's an integral part of the system for managing services and other things. To run a web server at least somewhat reliably you don't even need a lot of systemd knowledge but you still need to know some networking, firewalls, DNS, in general how the internet works, how to configure a web server and other services, some basic security. If you don't want to learn these things then there are managed services that you pay to do those things for you or you hire someone to run it for you. Just like you take your car to a mechanic when you're not interested in figuring out how to reassemble the engine.
Yeah, things can always be improved and made simpler but to create something fool-proof for the average person would take a huge amount of work and there would need to be a business opportunity there for someone to invest in that or there would need to be some passionate generous soul that would invest their time in a project like that.
And like I already mentioned, there are already solutions to the "it's too complicated" problem: 1) companies offering managed services, 2) companies/individuals for hire to do it for you.
Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?
I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly.
systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.
> Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers?
Traditionally, init scripts were installed into /etc but package managers (or at least some of them?) took/take care to not overwrite files under /etc but instead let you merge in the new changes.
I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates. Okay, makes sense, I need to use systemctl edit instead. But that opens a file that has everything commented out. Do I uncomment the [Unit] heading? What do I need to keep and where do I add my additions? I recall there being a comment at the start of this file, but unless I'm misremembering it doesn't answer that.
All I ask of it to do one thing - start something.service after other.service. yet it just refuses to order them this way. Why? I have no idea. I also have no idea where to start debugging a problem like this. There's a billion ways to try and do this after all: do I add Before=something to other.service? Do I add After=other to something.service? Both? Wants=something?