Systemd Change Allows For Stateless Systems With Tmpfs

[MoonMoon]

From your blog quote, that is exactly what etc-update is used for in gentoo builds. I'm pretty sure most distros have that covered.

etc-update is used to compare and merge older configuration files with new ones that come with a package update, both placed in /etc. If those new ones are actually pristine config files directly from the software developer or altered by the Gentoo developers is nothing that etc-update can determine, so it does not really fit into this case.

[crymsonpheonix]

That still doesn't make any sense though. Once a file is configured in /etc you'll have a completely redundant and incorrect file in /usr. It still doesn't make any sense.

So what are the three cases that etc-update finds?
1) you have an unmodified config file and you accept the defaults, a software update requires a new config file, and there is a conflict
In this case I don't care about "my" file it etc, I would be fine with emerge just override that file silently. if the file was in /usr/share/etc emerge could do this automatically for me because it knows that the file in /usr/share/etc shouldn't be modified and it can always safely replace it

2) You have a modified file in etc and the "new" file is just an unmodified version of the file already in etc
In this case I don't want the "new" file, if it was in /usr/share/etc I wouldn't need to care because there wouldn't be a conflict

3) I have a modified config file in etc, and the new config file has more/less/different options and I need to sort those out.
In an ideal world this wouldn't be a problem either. The daemon would load the default configuration in /usr/share/etc, then override any values found in /etc, so again I wouldn't need etc-update
The reality is of course not the ideal, most daemons only read one configuration file, so you need some sort of tool that knows about changes in the config file and alerts you to those changes immediately after running emerge. etc-update is not that tool, however.

So, really etc-update is a tool created because the traditional handling of config files is sub-optimal; it's a band-aid fixing the symptoms of a problem that the systemd devs want to solve.

[duby229]

So what are the three cases that etc-update finds?
1) you have an unmodified config file and you accept the defaults, a software update requires a new config file, and there is a conflict
In this case I don't care about "my" file it etc, I would be fine with emerge just override that file silently. if the file was in /usr/share/etc emerge could do this automatically for me because it knows that the file in /usr/share/etc shouldn't be modified and it can always safely replace it

2) You have a modified file in etc and the "new" file is just an unmodified version of the file already in etc
In this case I don't want the "new" file, if it was in /usr/share/etc I wouldn't need to care because there wouldn't be a conflict

3) I have a modified config file in etc, and the new config file has more/less/different options and I need to sort those out.
In an ideal world this wouldn't be a problem either. The daemon would load the default configuration in /usr/share/etc, then override any values found in /etc, so again I wouldn't need etc-update
The reality is of course not the ideal, most daemons only read one configuration file, so you need some sort of tool that knows about changes in the config file and alerts you to those changes immediately after running emerge. etc-update is not that tool, however.

So, really etc-update is a tool created because the traditional handling of config files is sub-optimal; it's a band-aid fixing the symptoms of a problem that the systemd devs want to solve.

Yeah, when I made that statement I was still under the impression that it was going to be dealing with whole files.

Mirroring the entire file would of course be silly thing to do. You only override what you are actually changing.

I don't know whether etc-update or portage will be able to deal with this. I don't know enough to say if portage can handle this type of configuration system. Or how easy or hard it may be to support.

[Ericg]

Yeah, when I made that statement I was still under the impression that it was going to be dealing with whole files.



I don't know whether etc-update or portage will be able to deal with this. I don't know enough to say if portage can handle this type of configuration system. Or how easy or hard it may be to support.

Well thats the thing though, portage will update /usr/lib/systemd/system (and any other pieces of software that ship default unmodified config files for backup in /usr/). Those copies are supposed to be left alone, and if you need them you `cp ` them where you need them to go, if necessary. So portage should be able to update those perfectly fine. What it only has to worry about is modified config files / config snippets under /etc/.

The user should -never- be changing backup config files under /usr/ because 1) Those changes will be overwritten on package update ANYWAY, 2) they are MEANT to be safe, sane defaults so that if you butcher the working copy you have a fallback to start fresh on.

If you want to override the default settings you copy the file to /etc/ and make changes there. Most programs prioritize config files under /etc/ over /usr/ unless you do something like pass "--conf=/usr/[...]". The backup, default copy can still be updated safely by the package, and your changes are kept as-is.

systemd does something a little different. It reads in /usr/lib/systemd/system as the defaults, then it checks /etc/systemd/system to see if there are any .service files that have the same name in both directories. If there are, systemd opens that /etc/ .service file and reads it in, using the /etc/ version to replace specific directives.

So lets say you installed xvfb (I literally picked a program at random)

xvfb's /usr/lib/systemd/system .service file says

[Unit]
Description=xinit with xvfb
After=network.target

[Service]
User=bitlbee
Group=bitlbee
ExecStart=/usr/bin/xvfb-run bash %h/.xinitrc

[Install]
WantedBy=multi-user.target

If I was 100% okay with everything in that service file, but I just wanted to change the user and group, then I'd make a /etc/systemd/system/xvfb.service file that had the contents

[Service]
User=bitlbee-custom
Group=bitlbee-custom

systemd would read in the /usr/ file, check /etc/, see a double-up and read in my changes from /etc/, and swap out the user/group listed in /usr/ with the ones I specified in /etc/.

This way, lets say that xvfb's developers decided that it needed a dependency on ssh being active before starting (i dont know why it would, again, pulling an example out of my ass). They could update the /usr/ service to say After=sshd.service, I wouldn't have to resolve the .rpmnew .pac.new (insert-whatever-gentoo's-is) conflict. The default would get changed to be After=sshd.service, and I'd keep my changes for user/group, and the world keeps on spinning.

[pal666]

... /etc/ for system-wide settings, nothing else
well.. /lib/ for kernel/modules settings

you are imbecile
/usr comes with distro
/etc is edited by hand
is it so hard to understand?

[Ericg]

you are imbecile
/usr comes with distro
/etc is edited by hand
is it so hard to understand?

Now now, pal, this was a half decent systemd discussion. Don't poison the well by name-calling.

[grndzro]

I think Michael posts these for the sheer enjoyment of seeing the systemd haters get their asses handed to them.

[magika]

I think Michael posts these for the sheer enjoyment of seeing the systemd haters get their asses handed to them.

For clicks, obviously.

[nanonyme]

You guys probably realize that usr-merge like in Fedora is most likely a prerequisite for this? In such a system /bin is the same thing as /usr/bin, /lib is the same thing as /usr/lib etc

[CrystalGamma]

You guys probably realize that usr-merge like in Fedora is most likely a prerequisite for this? In such a system /bin is the same thing as /usr/bin, /lib is the same thing as /usr/lib etc

Well, that's how my system has been for more than a year, and I think most other distros are going there too.