Distributing OS-specific Changes

12 views
Skip to first unread message

David Hobach

unread,
Jun 19, 2021, 2:43:00 AM6/19/21
to qubes...@googlegroups.com
Dear all,

How do you distribute modifications specific to certain template operating systems?

I considered sending the seemingly trivial 2-line PR for [5988], but then noticed that
modifying upstream systemd configuration can be done in many ways with each having Pros and Cons and none seeming straightforward:

1. Maintain an own systemd package for 2+ distributions:
Oh no, I'm a simple man... This doesn't scale well.
2. Add it to the builder process as 40_*post script or so:
The next time an upstream maintainer changes the modified lines, we're back to the maintainer state.
3. Use dom0 salt:
Similar to 2. unless one does it after every update. This would however force users to update their OS via salt for the optimal experience? Not great - I like my "apt-get dist-upgrade".
It might be Okayish for this particular change as the configuration is almost never touched by upstream.
4. Maintain some distro-specific code that is called after every update:
Quite a project by itself & another maintenance burden, but probably scales better than 1. A quick look however led me to the conclusion that e.g. for apt the callbacks are all quite shaky and pass little information to the called script (nothing about the executed action for example).
5. Some hopefully obvious solution that I missed?

[5988] https://github.com/QubesOS/qubes-issues/issues/5988

Best Regards
David

Rusty Bird

unread,
Jun 19, 2021, 8:00:29 AM6/19/21
to David Hobach, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi David,
This is about the watchdog thing? You could add another[1] systemd
"drop-in"[2] file - systemd-logind.service.d/30_qubes.conf - to the
qubes-core-agent-systemd package, containing

[Service]
WatchdogSec=0

1. https://github.com/QubesOS/qubes-core-agent-linux/tree/master/vm-systemd
2. https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Rusty
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmDN0wdfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8WGw//VNTs/Asu2bkO29xK/bV/zlDGqfENBy7+l7fBIGYsWG3Va5hfHWjHal6I
PujNgBCqIFH9OtDOEK0hpGgX+f94HgQ690e8igqnxqE4EiajuYtY6e7izZZuvMYM
nAkxjHdvh+nAt7EAG+fxqyN227OPhHZ+3NxkWEhy/yh/eak6SKpCHJDUij1yStZK
jT25z8SwGuTv4SqgXKcK5wdAvvDmE4ciSJj45SSL8rLt87cBXWiTznzxPGsHzePn
BvRmO+MFFSbKMOmVm+9d8V1ZU16Ee76Q7bDAPvdgiTIUPoSkW1Y8V3lp6YFfhLnn
xD7VD78NEb8Pf4/b65dhgV+L3CaA+Fdqoqby+uLfCNmBRn6z+PNYfqdu7BNIf0yV
Zwt7LeQbP+ExETxiV93qbFzWiDdDqgUlkF3AD/YvGVtW3+0to49+XAtN+EAaqdaZ
MwBH4OcA7NvqUBZ9ZRoDFgJdTUH3T2UTdIwf2Hn7WSMcZxlBJb0vNlDxZdl8WakD
xQrTYmCYbhHS6CPqA0BF6PLYD+eRwi8HbapbBsUijUtaPd+/R+zMzcba7bBerRz2
6SMA0QGCluWKJTS6dnyJBF0tgCOJiGGjtNCUGw7bCY61JwmuLwXLxPe+t51R086p
9cmqLhJzRKFl2/pGm5dP7gWpChi4vWmaeFDeufh8ZP3Hqlq+Nzw=
=+NKQ
-----END PGP SIGNATURE-----

David Hobach

unread,
Jun 20, 2021, 2:40:48 AM6/20/21
to qubes...@googlegroups.com
On 6/19/21 1:20 PM, Rusty Bird wrote:
> Hi David,
>
>> How do you distribute modifications specific to certain template operating systems?
>
>> I considered sending the seemingly trivial 2-line PR for [5988], but then noticed that
>> modifying upstream systemd configuration can be done in many ways with each having Pros and Cons and none seeming straightforward:
>
>> 1. Maintain an own systemd package for 2+ distributions:
>> Oh no, I'm a simple man... This doesn't scale well.
>> 2. Add it to the builder process as 40_*post script or so:
>> The next time an upstream maintainer changes the modified lines, we're back to the maintainer state.
>> 3. Use dom0 salt:
>> Similar to 2. unless one does it after every update. This would however force users to update their OS via salt for the optimal experience? Not great - I like my "apt-get dist-upgrade".
>> It might be Okayish for this particular change as the configuration is almost never touched by upstream.
>> 4. Maintain some distro-specific code that is called after every update:
>> Quite a project by itself & another maintenance burden, but probably scales better than 1. A quick look however led me to the conclusion that e.g. for apt the callbacks are all quite shaky and pass little information to the called script (nothing about the executed action for example).
>> 5. Some hopefully obvious solution that I missed?
>
>> [5988] https://github.com/QubesOS/qubes-issues/issues/5988
>
> This is about the watchdog thing? You could add another[1] systemd
> "drop-in"[2] file - systemd-logind.service.d/30_qubes.conf - to the
> qubes-core-agent-systemd package, containing
>
> [Service]
> WatchdogSec=0
>
> 1. https://github.com/QubesOS/qubes-core-agent-linux/tree/master/vm-systemd
> 2. https://www.freedesktop.org/software/systemd/man/systemd.unit.html

That's it.

Looks like I should've read more about systemd, thanks for the hint!

Reply all
Reply to author
Forward
0 new messages