Re: [systemd-devel] Hints for upgrading systemd on a running system

[Paul Menzel]

Dear Lennart and others,


Thank you for your prompt replies.


Am 20.02.2018 um 23:12 schrieb Lennart Poettering:

On Di, 20.02.18 20:00, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:



We finally are going to upgrade from a very old systemd version 27 from 2011
to the current systemd v237. (Historical reasons.)

Anyway, I already was told about `systemctl daemon-reexec`, and we got it
working.


While we try to ensure that live upgrades of PID 1 like that work
quite well, this is generally tested only for small steps. Jumping 6
years ahead in one go is not something people typically test.


Indeed, but it seems to work. During the upgrade you have to make sure, 
that both versions are installed in parallel when doing `systemctl 
daemon-reexec`, so the old systemd still finds it dependencies/libraries 
and can terminate properly. Then the old version can be removed.



After that, looking at the output of `systemctl`, there are many units from
the old version, which were removed in the meantime.

```
$ systemctl --state=not-found
   UNIT LOAD  ACTIVE   SUB DESCRIPTION
● dev-hugepages.automount  not-found active   waiting
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting
sys-kernel-security.automount
● auditd.service   not-found inactive dead
auditd.service
● console-kit-log-system-start.service not-found active   exited
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead
display-manager.service
● hwclock-load.service not-found active   exited
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead
plymouth-start.service
● remount-rootfs.service   not-found active   exited
remount-rootfs.service
● syslog.service   not-found inactive dead
syslog.service
● systemd-kmsg-syslogd.service not-found active   running
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead
systemd-sysusers.service
● udev-retry.service   not-found active   exited
udev-retry.service
● udev-settle.service  not-found active   exited
udev-settle.service
● systemd-logger.socketnot-found active   listening
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active
cryptsetup.target
● syslog.targetnot-found active   active
syslog.target


My recommendation: simply reboot. That should clean up everything
properly.

Note that PID 1 itself is probably pretty Ok with such a massive
update in one step, but the unit files have been rearranged quite a
bit since then. Downstream distributions generally expect you to
reboot even between single-step distro updates, but this becomes much
more of a necessity if you jump even further.


But if reboot wouldn’t be an option, is there a way to get rid of 
not-found services?



Note that systemd upstream currently requires kernel 3.13 at least
which was released in 2014. Hence, if you update from a 2011 system
you have to reboot anyway, already to update the kernel...


We already run later Linux Kernels, so that is not a problem. But thank 
you for mentioning it.



Do I need to stop those manually beforehand, or is there another way to
clean up?

Is the recommended update procedure documented somewhere?


Usually distributions document that invididually as systemd is just
one component of many that make up the distribution.


Understood.


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] forking PIDFile question

[Jonathan de Boyne Pollard]

st...@goodey.org:

[Service]

Type=forking



Your program has an -f option to stop it from vainly trying to 
re-daemonize itself.  Use it; and do not use Type=forking in the first 
place.


* 
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise


The supplied systemd service unit that comes packaged by Ubuntu/Debian 
does this.  You can ignore its use of -s 1 , as systemd will log the 
program's standard output and -s 0 will do quite well.


* 
https://sources.debian.org/src/lcdproc/0.5.9-2/debian/lcdproc.LCDd.service/


st...@goodey.org:


[server]

User=nobody


Also, do not abuse nobody for dæmons.  Use a dedicated unprivileged user 
account, such as (for example) lcdproc.  Name the unprivileged user 
account in the service unit in a User= setting, and using filesystem 
ACLs or otherwise grant it nothing except the permission to open 
/dev/ttyUSB0 for writing and to open the configuration file for reading.


* http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html

Currently, you are running your program as the superuser with a 
configuration file owned by an unprivileged user.  This is a backdoor 
into your system, as anyone who compromises that unprivileged user 
account (which is the one that you run your WWW browser as, and that you 
use to run software build systems and other programs downloaded from 
other people that you do not know, ne?) can rewrite the configuration 
file and thereby persuade a superuser-privileged process to open an 
arbitrary file and write stuff (which it does before it attempts to 
detect whether it is running as the superuser).

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Lennart Poettering]

On Di, 20.02.18 20:06, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 20.02.2018 um 20:00 schrieb Paul Menzel:
> > Dear systemd folks,
> > 
> > We finally are going to upgrade from a very old systemd version 27 from
> > 2011 to the current systemd v237. (Historical reasons.)
> 
> hopefully you have a working backup
> 
> > Anyway, I already was told about `systemctl daemon-reexec`, and we got
> > it working.
> 
> the "reexec" is misleading because it's not possible to terminate PID1 and
> start it again on a running system with a new binary

Hmm? "systemctl daemon-reexec" is supposed to support upgrades between
systemd versions. Doing massive jumps v27 → v237 in one go isn't
precisely well tested, but smaller ones should work quite well.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Lennart Poettering]

On Di, 20.02.18 20:00, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> Dear systemd folks,
> 
> 
> We finally are going to upgrade from a very old systemd version 27 from 2011
> to the current systemd v237. (Historical reasons.)
> 
> Anyway, I already was told about `systemctl daemon-reexec`, and we got it
> working.

While we try to ensure that live upgrades of PID 1 like that work
quite well, this is generally tested only for small steps. Jumping 6
years ahead in one go is not something people typically test.

> After that, looking at the output of `systemctl`, there are many units from
> the old version, which were removed in the meantime.
> 
> ```
> $ systemctl --state=not-found
>   UNIT LOAD  ACTIVE   SUB DESCRIPTION
> ● dev-hugepages.automount  not-found active   waiting
> dev-hugepages.automount
> ● dev-mqueue.automount not-found active   waiting
> dev-mqueue.automount
> ● sys-kernel-debug.automount   not-found active   waiting
> sys-kernel-debug.automount
> ● sys-kernel-security.automountnot-found active   waiting
> sys-kernel-security.automount
> ● auditd.service   not-found inactive dead
> auditd.service
> ● console-kit-log-system-start.service not-found active   exited
> console-kit-log-system-start.service
> ● display-manager.service  not-found inactive dead
> display-manager.service
> ● hwclock-load.service not-found active   exited
> hwclock-load.service
> ● plymouth-quit-wait.service   not-found inactive dead
> plymouth-quit-wait.service
> ● plymouth-start.service   not-found inactive dead
> plymouth-start.service
> ● remount-rootfs.service   not-found active   exited
> remount-rootfs.service
> ● syslog.service   not-found inactive dead
> syslog.service
> ● systemd-kmsg-syslogd.service not-found active   running
> systemd-kmsg-syslogd.service
> ● systemd-remount-api-vfs.service  not-found active   exited
> systemd-remount-api-vfs.service
> ● systemd-sysusers.service not-found inactive dead
> systemd-sysusers.service
> ● udev-retry.service   not-found active   exited
> udev-retry.service
> ● udev-settle.service  not-found active   exited
> udev-settle.service
> ● systemd-logger.socketnot-found active   listening
> systemd-logger.socket
> ● systemd-shutdownd.socket not-found active   listening
> systemd-shutdownd.socket
> ● cryptsetup.targetnot-found active   active
> cryptsetup.target
> ● syslog.targetnot-found active   active
> syslog.target

My recommendation: simply reboot. That should clean up everything
properly.

Note that PID 1 itself is probably pretty Ok with such a massive
update in one step, but the unit files have been rearranged quite a
bit since then. Downstream distributions generally expect you to
reboot even between single-step distro updates, but this becomes much
more of a necessity if you jump even further.

Note that systemd upstream currently requires kernel 3.13 at least
which was released in 2014. Hence, if you update from a 2011 system
you have to reboot anyway, already to update the kernel...

> Do I need to stop those manually beforehand, or is there another way to
> clean up?
> 
> Is the recommended update procedure documented somewhere?

Usually distributions document that invididually as systemd is just
one component of many that make up the distribution.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Reindl Harald]

Am 20.02.2018 um 22:04 schrieb Mantas Mikulėnas:
On Tue, Feb 20, 2018, 21:06 Reindl Harald > wrote:



Am 20.02.2018 um 20:00 schrieb Paul Menzel:
 > Dear systemd folks,
 >
 > We finally are going to upgrade from a very old systemd version
27 from
 > 2011 to the current systemd v237. (Historical reasons.)

hopefully you have a working backup

 > Anyway, I already was told about `systemctl daemon-reexec`, and
we got
 > it working.

the "reexec" is misleading because it's not possible to terminate PID1
and start it again on a running system with a new binary


But you don't *have to* terminate pid1 to change the binary – you can 
just exec the new one. Hence the "reexec".


It's possible. That's how initramfs works


a lot of other threads here made it clear that there is not much 
difference between "daemon-reload" and "daemon-reexec" at all in the 
past and i strongly doubt that it's technically possible to seamless 
switch from version 27 (the first Fedora GA AFAIK hat version 44) to 237 
and keep the system happily running as like nothing has changed without 
reboot

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Mantas Mikulėnas]

On Tue, Feb 20, 2018, 21:06 Reindl Harald  wrote:

>
>
> Am 20.02.2018 um 20:00 schrieb Paul Menzel:
> > Dear systemd folks,
> >
> > We finally are going to upgrade from a very old systemd version 27 from
> > 2011 to the current systemd v237. (Historical reasons.)
>
> hopefully you have a working backup
>
> > Anyway, I already was told about `systemctl daemon-reexec`, and we got
> > it working.
>
> the "reexec" is misleading because it's not possible to terminate PID1
> and start it again on a running system with a new binary
>

But you don't *have to* terminate pid1 to change the binary – you can just
exec the new one. Hence the "reexec".

It's possible. That's how initramfs works.

> --

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Hints for upgrading systemd on a running system

[Paul Menzel]

Dear systemd folks,


We finally are going to upgrade from a very old systemd version 27 from 
2011 to the current systemd v237. (Historical reasons.)


Anyway, I already was told about `systemctl daemon-reexec`, and we got 
it working.


After that, looking at the output of `systemctl`, there are many units 
from the old version, which were removed in the meantime.


```
$ systemctl --state=not-found
  UNIT LOAD  ACTIVE   SUB 
DESCRIPTION
● dev-hugepages.automount  not-found active   waiting 
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting 
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting 
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting 
sys-kernel-security.automount
● auditd.service   not-found inactive dead 
auditd.service
● console-kit-log-system-start.service not-found active   exited 
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead 
display-manager.service
● hwclock-load.service not-found active   exited 
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead 
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead 
plymouth-start.service
● remount-rootfs.service   not-found active   exited 
remount-rootfs.service
● syslog.service   not-found inactive dead 
syslog.service
● systemd-kmsg-syslogd.service not-found active   running 
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited 
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead 
systemd-sysusers.service
● udev-retry.service   not-found active   exited 
udev-retry.service
● udev-settle.service  not-found active   exited 
udev-settle.service
● systemd-logger.socketnot-found active   listening 
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening 
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active 
cryptsetup.target
● syslog.targetnot-found active   active 
syslog.target


LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.

21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
```

Do I need to stop those manually beforehand, or is there another way to 
clean up?


Is the recommended update procedure documented somewhere?


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Michael Biebl]

2018-02-20 20:00 GMT+01:00 Paul Menzel :
>
> Do I need to stop those manually beforehand, or is there another way to
> clean up?

reboot.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

[Reindl Harald]

Am 20.02.2018 um 20:00 schrieb Paul Menzel:

Dear systemd folks,

We finally are going to upgrade from a very old systemd version 27 from 
2011 to the current systemd v237. (Historical reasons.)


hopefully you have a working backup

Anyway, I already was told about `systemctl daemon-reexec`, and we got 
it working.


the "reexec" is misleading because it's not possible to terminate PID1 
and start it again on a running system with a new binary


After that, looking at the output of `systemctl`, there are many units 
from the old version, which were removed in the meantime.


i doubt that anybody has done such a version jump at all and even if the 
environment won't match anyways - you need to reboot and hope it works 
as well as be prepared for the case it won't boot - it's that easy


make at least sure that initrd has been updated with the new systemd!


$ systemctl --state=not-found
   UNIT LOAD  ACTIVE   SUB DESCRIPTION
● dev-hugepages.automount  not-found active   waiting 
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting 
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting 
sys-kernel-debug.automount
● sys-kernel-security.automount    not-found active   waiting 
sys-kernel-security.automount
● auditd.service   not-found inactive dead 
auditd.service
● console-kit-log-system-start.service not-found active   exited 
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead 
display-manager.service
● hwclock-load.service not-found active   exited 
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead 
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead 
plymouth-start.service
● remount-rootfs.service   not-found active   exited 
remount-rootfs.service
● syslog.service   not-found inactive dead 
syslog.service
● systemd-kmsg-syslogd.service not-found active   running 
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited 
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead 
systemd-sysusers.service
● udev-retry.service   not-found active   exited 
udev-retry.service
● udev-settle.service  not-found active   exited 
udev-settle.service
● systemd-logger.socket    not-found active   listening 
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening 
systemd-shutdownd.socket
● cryptsetup.target    not-found active   active 
cryptsetup.target
● syslog.target    not-found active   active 
syslog.target


LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
```

Do I need to stop those manually beforehand, or is there another way to 
clean up?


Is the recommended update procedure documented somewhere?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Lennart Poettering]

On Di, 20.02.18 17:29, Iain Lane (i...@orangesquash.org.uk) wrote:

> On Tue, Feb 20, 2018 at 06:04:47PM +0100, Lennart Poettering wrote:
> > On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:
> > > I'm not sure, though, what the best way to specify this in a timer unit
> > > would be. Perhaps either a new timezone specification "local", or a
> > > boolean flag UpdateWithTimezoneChange. "local" would act like you
> > > specified the current timezone, but we would go away and recalculate
> > > the time on a timezone change.
> > 
> > If you don't specify a timezone in timer expression you actually
> > reference the local time. The only issue is that we don't recognize
> > timezone changes...
> 
> That's right. This is the intended behaviour though, so I'm proposing a
> way to opt into something different. My feeling is that "local" is a
> confusing name, but we could hash that out at a later stage.

I think we should fix systemd so that specifying no timezone means
"follow the local timezone". I wouldn't even call that an API
breakage, but just a fix.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Lennart Poettering]

On Di, 20.02.18 11:20, Dan Nicholson (nichol...@endlessm.com) wrote:

> On Tue, Feb 20, 2018 at 11:04 AM, Lennart Poettering
>  wrote:
> > On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:
> >
> >> I also don't know how we'd get notified of the timezone changing.
> >> inotify on /etc/timezone?
> >
> > /etc/timezone is usually a symlink, and iirc we can't install inotify
> > on a symlink (only in the containing dir, but that means a lot more
> > wakeups).
> 
> Drive-by comment: the file you want to watch is /etc/localtime. That's
> what glibc reads to get the default timezone in preference to the $TZ
> environment variable -
> http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
> /etc/timezone is just a Debian thing to keep the name of the timezone.
> I'm not sure what uses that file.

True, we dropped /etc/timezone a long time ago. /etc/localtime is the
way to go, and the timezone is supposed to be read from the symlink
content.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Iain Lane]

On Tue, Feb 20, 2018 at 06:04:47PM +0100, Lennart Poettering wrote:
> On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:
> > I'm not sure, though, what the best way to specify this in a timer unit
> > would be. Perhaps either a new timezone specification "local", or a
> > boolean flag UpdateWithTimezoneChange. "local" would act like you
> > specified the current timezone, but we would go away and recalculate
> > the time on a timezone change.
> 
> If you don't specify a timezone in timer expression you actually
> reference the local time. The only issue is that we don't recognize
> timezone changes...

That's right. This is the intended behaviour though, so I'm proposing a
way to opt into something different. My feeling is that "local" is a
confusing name, but we could hash that out at a later stage.

> Could you file an RFE issue about this on github?

Yep. I filed #8233 now. Let's carry on there.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Dan Nicholson]

On Tue, Feb 20, 2018 at 11:04 AM, Lennart Poettering
 wrote:
> On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:
>
>> I also don't know how we'd get notified of the timezone changing.
>> inotify on /etc/timezone?
>
> /etc/timezone is usually a symlink, and iirc we can't install inotify
> on a symlink (only in the containing dir, but that means a lot more
> wakeups).

Drive-by comment: the file you want to watch is /etc/localtime. That's
what glibc reads to get the default timezone in preference to the $TZ
environment variable -
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
/etc/timezone is just a Debian thing to keep the name of the timezone.
I'm not sure what uses that file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Lennart Poettering]

On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:

> Hi systemd friends,
> 
> Sorry if this has been discussed already.
> 
> I'm working on an alarm program. To allow the program to be shut down
> between alarms, they are represented as systemd timers using OnCalendar
> specifications. This mostly works but I think there is one wrinkle
> remaining - they don't handle timezone transitions but always trigger in
> the timezone that was in use when they were started.
> 
> In addition to alarms, you might also want this to schedule housekeeping
> tasks or backups to happen in the night. I think the semantics would be
> something like -
> 
>   * When changing timezones, ensure timers will activate at their
> configured time in the new local timezone.
>   * Ignore any activation times that are skipped over due to a timezone
> change.
> 
> I'm not sure, though, what the best way to specify this in a timer unit
> would be. Perhaps either a new timezone specification "local", or a
> boolean flag UpdateWithTimezoneChange. "local" would act like you
> specified the current timezone, but we would go away and recalculate
> the time on a timezone change.

If you don't specify a timezone in timer expression you actually
reference the local time. The only issue is that we don't recognize
timezone changes...

Could you file an RFE issue about this on github?

> I also don't know how we'd get notified of the timezone changing.
> inotify on /etc/timezone?

/etc/timezone is usually a symlink, and iirc we can't install inotify
on a symlink (only in the containing dir, but that means a lot more
wakeups).

The alternative is to watch timedated's bus signals, but quite frankly
I am not too keen on that, since PID 1 depending on service's APIs is
always messy, and means early-boot timezone changes couldn't be
covered (which are not unlikely, since timezone info can be
distributed via dhcp)

So, yeah, maybe a careful /etc inotify watch would be the best option
here after all. Happy to take a PR for that ;-)

(We can probably reuse similar code in journald, to fix #6589)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

[Lennart Poettering]

On Di, 20.02.18 07:17, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> > If your kernel or initrd are located on encrypted filesystem you need
> > bootloader that can read them.
> 
> And can systemd-boot read it?

sd-boot is ultimately just a dumb menu program. It just enumerates
kernels and runs them. The file system support is the firmware's own
FAT driver or whatever else it supports. It doesn't do anything hard
really, it comes with no device or file system drivers on its.

hence: if your firmware doesn't support encrypted file systems then
sd-boot won't support it either. And most likely your firmware does
not support that.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

[Lennart Poettering]

On Mo, 19.02.18 23:16, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> Dear systemd folks,
> 
> 
> Having a system with UEFI, what is the state of the art to use full disk
> encryption? I read the article in the Arch Linux wiki [1], and it still
> using GRUB. There is an blog post from 2016 using systemd-boot [2].

By "full disk encryption" you mean actually the *full* disk?
i.e. without any partition table you want to encrypt the raw block
device, and then still be able to boot from that?

That's not possible on off-the-shelf systems. The firmware looks for
the ESP and generally only supports unencrypted FAT for that, except
for Mac machines where it can be some other file systems too.

Hence, instead you'd usually only encrypt the actual Linux partition
and leave the ESP partition unencrypted. And most initrds should
support that easily and out of the box. At least Dracut is happy with that.

> If there was a way without LVM, I’d prefer that.

LVM is one user of the kernel's DM layer, and cryptsetup/LUKS
another. However, LVM doesn't use cryptsetup/LUKS and vice versa.

> Are there new programs or features in the systemd ecosystem making
> the setup easy?

Well, we provide all the hookups to make cryptsetup support work
nicely, but of course it's up to your distro/initrd implementation to
make use of that.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] timezone aware timers

[Iain Lane]

Hi systemd friends,

Sorry if this has been discussed already.

I'm working on an alarm program. To allow the program to be shut down
between alarms, they are represented as systemd timers using OnCalendar
specifications. This mostly works but I think there is one wrinkle
remaining - they don't handle timezone transitions but always trigger in
the timezone that was in use when they were started.

In addition to alarms, you might also want this to schedule housekeeping
tasks or backups to happen in the night. I think the semantics would be
something like -

  * When changing timezones, ensure timers will activate at their
configured time in the new local timezone.
  * Ignore any activation times that are skipped over due to a timezone
change.

I'm not sure, though, what the best way to specify this in a timer unit
would be. Perhaps either a new timezone specification "local", or a
boolean flag UpdateWithTimezoneChange. "local" would act like you
specified the current timezone, but we would go away and recalculate
the time on a timezone change.

I also don't know how we'd get notified of the timezone changing.
inotify on /etc/timezone?

WDYT? (Should I report this as an issue instead?)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel