[arch-dev-public] systemd 216 coming soon to testing
Hi, I'm working on the final pieces of systemd 216 packaging (will push to [testing] tonight EST barring the unforseen). As always, there's a number of new features/bugs, but a few gotchas might want special mention: For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups). - The never-ending NTP provider dance continues. Effective immediately, all files in /usr/lib/systemd/ntp-units.d are defunct, and will no longer be read. In exchange, extra/ntp and community/openntpd must add "Conflicts=systemd-timesyncd.service" to their service file. (chrony is already taken care of). timedated will no longer attempt to activate implementations other than timesyncd. So, use timesyncd unless you really care about having a full blown NTP server running. This currently requires systemd-networkd to be *running* (but not necessarily actively configuring anything). In 217, this requirement will likely be lifted. For users: - systemd no longer tells the kernel about the timezone when the RTC is set to localtime. An immediately visible effect of this might be that timestamps on FAT filesystems will be "wrong" (displayed in UTC). There's no way around this unless you play with settimeofday() yourself before systemd starts (this idea comes with zero warranty). Full NEWS file: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS Cheers, d
On Wed, Aug 20, 2014 at 02:25:24PM -0400, Dave Reisner wrote:
Hi,
I'm working on the final pieces of systemd 216 packaging (will push to [testing] tonight EST barring the unforseen). As always, there's a number of new features/bugs, but a few gotchas might want special mention:
For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups).
- The never-ending NTP provider dance continues. Effective immediately, all files in /usr/lib/systemd/ntp-units.d are defunct, and will no longer be read. In exchange, extra/ntp and community/openntpd must add "Conflicts=systemd-timesyncd.service" to their service file. (chrony is already taken care of). timedated will no longer attempt to activate implementations other than timesyncd. So, use timesyncd unless you really care about having a full blown NTP server running. This currently requires systemd-networkd to be *running* (but not necessarily actively configuring anything). In 217, this requirement will likely be lifted.
For users: - systemd no longer tells the kernel about the timezone when the RTC is set to localtime. An immediately visible effect of this might be that timestamps on FAT filesystems will be "wrong" (displayed in UTC). There's no way around this unless you play with settimeofday() yourself before systemd starts (this idea comes with zero warranty).
So apparently FAT has an undocumented "time_offset" mount option which takes a ($value >= -12 && $value <= 12) to offset timestamps displayed in the FS.
Full NEWS file:
http://cgit.freedesktop.org/systemd/systemd/tree/NEWS
Cheers, d
On 20/08/2014 20:25, Dave Reisner wrote:
For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups). I'm enthused by this feature and systemd-sysusers can offer a more standard way for managing system users across distro. Nevertheless, It would be nice if we do not fall into the shortcut of not removing users bound to a package when we remove it. That avoid manual removing and I don't see a drawback for doing this.
Do you know why they don't implement the same logic (--create, --clean) as systemd-tmpfiles in systemd-sysusers? -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 24/08/14 04:54 PM, Sébastien Luttringer wrote:
On 20/08/2014 20:25, Dave Reisner wrote:
For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups). I'm enthused by this feature and systemd-sysusers can offer a more standard way for managing system users across distro. Nevertheless, It would be nice if we do not fall into the shortcut of not removing users bound to a package when we remove it. That avoid manual removing and I don't see a drawback for doing this.
Do you know why they don't implement the same logic (--create, --clean) as systemd-tmpfiles in systemd-sysusers?
There will often be files left behind owned by that uid/gid, and deleting the user/group will free up the id to be consumed by the next user/group. There's a potential to leak sensitive information like passwords. Fedora and systemd choose to ignore the ickiness of having dead system users/groups to avoid that issue.
participants (3)
-
Daniel Micay
-
Dave Reisner
-
Sébastien Luttringer