Re: Using timedatectl on a readonly rootfile system using mender

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Sa, 05.09.20 09:49, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote:

> 05.09.2020 01:05, Lennart Poettering пишет:
> >
> > I explained this already. DNS server data today is much less config
> > than state, acquired dynamically via DHCP, hence most distros don#t
> > configure it in /etc so much anymore, but manage it in /run (where
> > transient state is generally kept), and only keep a compat symlink in
> > /etc. If you try to convince people though that the local timezone
> > should just be transient state and not persistent config you'll have a
> > hard time. I for one am certainly not convinced that the timezones are
> > state...
> >
>
> Sorry? glibc has absolutely no problems with /etc/localtime being link
> into /run, /var or whatever else (nor has it problems with this file
> being normal file and not a link) as long as content of this file is
> valid time zone definition. The only piece of software that has problem
> with it is systemd. So may be you should stop finger pointing and simply
> explain why *systemd* demands that /etc/localtime be specific
> symlink.

systemd is fine with with it being a bind mount, a regular file or a
symlink to whatever as well.

But we'll write it out as a symlink to the tz data files in
/usr/share/.

Also, when we read the data back we can only derive the tz location
string from the setting if its a symlink to the tz data files, since
the information about the location is only encoded in the path not in
the data files themselves. i.e. "Europe/Berlin" is nothing you can
derive from the data files, so we derive it from the symlink
contents. glibc doesn't ever do that, we do however, since people
typicall want to know what the current setting is.

For all our tools that write stuff to /etc, i.e. *write*
configuration, we can do so only if /etc is writable. That's true for
the locale settings, the vconsole settings, for timezones settings and
hostname settings. It's also true for seat assignments by logind, for
service enablement by systemctl, for portable services hook-ups and so
on and so on and so on.

We write to /etc because that it is generally where people on Linux
accepted that persistent config should be placed. I seriously doubt
that that is news to you. If you make that read-only that's entirely
fine, but then systemd's tools cannot change config for you, but I
think that's totally OK, by making it read-only you explicitly want to
disallow changes to the settings, so systemd should accept that and
also refuse it to clients.

If you want to manage a file in /etc/ in a completely different way,
then that's entirely OK. You could use git, or ansible, your private
shell script or whatever else floats your boat. There's no need to
involve the systemd tools for managing any of them, and systemd will
honour what you put there regardless how you write it there.

But systemd's own tools assume that /etc read-only means "config
read-only" and we honour that, and I think htat's not surprising and
most in line with what people would expect.

> And yes, in current world this is state and not persistent config. When
> I travel into another time zone I change state of my system for this
> timezone. Just like DNS server address. Guess what? There is DHCP option
> for time zone ... so how is it different from DNS server address?

For starters DNS info is per network connection and usually remains
valid exactly as long as the network it is associated with is
connected to. resolved for example manages DNS info like that: nothing
is persisted, and servers are added and dropped as ifaces come and go.

Timezone info might receive updates from automatic detection every now
and then, as you move around, but it's a lot more sticky: once the
timezone is updated it stays that way even for the next boot.

And yes, I am pretty sure some people disagree with this, or implement
stuff differently, but that doesn't change the fact that in general tz
info is persistent and DNS info not so much, though the lines are
blurry.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel