New package: os-update
Hi, there is a new package in Tumbleweed: os-update Since I'm lazy but wanted to have my non MicroOS servers also always up-to-date, I wrote this little package to make sure my servers are always fully patched like MicroOS: - runs regular via systemd.timer (default once a day) - Uses "zypper up" or "zypper dup" depending on the OS - If zypper reports "reboot necessary", a reboot will be triggered via rebootmgr, and if this is not running directly via "reboot". An enhancement could be to parse the services from the zypper ps -s output and restart the services... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Mo, Okt 31 2022 at 09:24:16 +0100, Thorsten Kukuk <kukuk@suse.de> wrote:
there is a new package in Tumbleweed: os-update
Since I'm lazy but wanted to have my non MicroOS servers also always up-to-date, I wrote this little package to make sure my servers are always fully patched like MicroOS:
- runs regular via systemd.timer (default once a day) - Uses "zypper up" or "zypper dup" depending on the OS - If zypper reports "reboot necessary", a reboot will be triggered via rebootmgr, and if this is not running directly via "reboot".
An enhancement could be to parse the services from the zypper ps -s output and restart the services...
Thanks for that, up to this point we used https://github.com/lrupp/suse-online-update in openSUSE infrastructure to keep systems up to date, however that didn't support Tumbleweed which we have to use with some services. This is a very nice potential replacement for that, which we were looking for. LCP [Jake] https://lcp.world/
On Mon, Oct 31, Jacob Michalskie wrote:
On Mo, Okt 31 2022 at 09:24:16 +0100, Thorsten Kukuk <kukuk@suse.de> wrote:
there is a new package in Tumbleweed: os-update
Since I'm lazy but wanted to have my non MicroOS servers also always up-to-date, I wrote this little package to make sure my servers are always fully patched like MicroOS:
- runs regular via systemd.timer (default once a day) - Uses "zypper up" or "zypper dup" depending on the OS - If zypper reports "reboot necessary", a reboot will be triggered via rebootmgr, and if this is not running directly via "reboot".
An enhancement could be to parse the services from the zypper ps -s output and restart the services...
Thanks for that, up to this point we used https://github.com/lrupp/suse-online-update in openSUSE infrastructure to keep systems up to date, however that didn't support Tumbleweed which we have to use with some services. This is a very nice potential replacement for that, which we were looking for.
Great to hear. I implemented now restarting of services, too. If there is anything else missing or not working, should be no problem to implement. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Hi, that works great for me, thank you! One glitch: When a library used by process 1 is updated, it is not catched by the service restarts. I manually do a systemctl daemon-reexec Is there a way to automate that? Here is the example of tonight: <snip> # LANG=C zypper ps The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ------+-------+-----+------+---------+---------+---------------------------- 1 | 0 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1 27013 | 27012 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1 You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # systemctl daemon-reexec # LANG=C zypper ps The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ------+-------+-----+------+---------+---------+---------------------------- 27013 | 27012 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1 You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # </snip> Remark: The remaining systemd process vanishes after logging out, so should not be a problem in automatic mode. -- Mit freundlichen Gruessen, Andreas Vetter
Hi, On Fri, Nov 25, Andreas Vetter wrote:
Hi, that works great for me, thank you!
One glitch: When a library used by process 1 is updated, it is not catched by the service restarts. I manually do a systemctl daemon-reexec
Is there a way to automate that?
Until now only restart of services is implemented (but here I did run into a zypper bug https://bugzilla.suse.com/show_bug.cgi?id=1205636, so some services will not be restarted) PID 1 is not a service and parsing of daemons not started by a service is not implemented. This would require a hardcoded list, how which process could be restarted... But of course: PRs are always welcome ;) Thorsten
Here is the example of tonight: <snip> # LANG=C zypper ps The following running processes use deleted files:
PID | PPID | UID | User | Command | Service | Files ------+-------+-----+------+---------+---------+---------------------------- 1 | 0 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1 27013 | 27012 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1
You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table.
No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # systemctl daemon-reexec # LANG=C zypper ps The following running processes use deleted files:
PID | PPID | UID | User | Command | Service | Files ------+-------+-----+------+---------+---------+---------------------------- 27013 | 27012 | 0 | root | systemd | | /usr/lib64/libcrypto.so.1.1
You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table.
No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # </snip>
Remark: The remaining systemd process vanishes after logging out, so should not be a problem in automatic mode.
--
Mit freundlichen Gruessen, Andreas Vetter
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Hi, Am Freitag, 25. November 2022, 13:37:40 CET schrieb Thorsten Kukuk:
Hi,
On Fri, Nov 25, Andreas Vetter wrote:
Hi, that works great for me, thank you!
One glitch: When a library used by process 1 is updated, it is not catched by the service restarts. I manually do a systemctl daemon-reexec
Is there a way to automate that?
Until now only restart of services is implemented (but here I did run into a zypper bug https://bugzilla.suse.com/show_bug.cgi?id=1205636, so some services will not be restarted)
Hm, interesting. I knew that zypper ps does not always find the right service, but didn't dig into. This might be the same problem. Another thing: What do you think of triggering a reboot, when dbus needs to be restarted? If positive, do we need an opt-out possibility for this? I'm working on that.
PID 1 is not a service and parsing of daemons not started by a service is not implemented. This would require a hardcoded list, how which process could be restarted... Do you think the following is worth a feature request to zypper? I am thinking of a extra Exit Code for restarting systemd PID1, in addition to 102 (reboot) and 103 (restart services).
But of course: PRs are always welcome ;)
Thorsten TIA, Andreas
[...] deleted example -- Mit freundlichen Gruessen, Andreas Vetter
Hi, since os-update is useful on Leap: Are you willing to submit it to Leap/Backports 15.5? Or would you mind, if I do it and add it as a feature in https://code.opensuse.org/leap/features ? -- Mit freundlichen Gruessen, Andreas Vetter
Hi, On Fri, Dec 09, Andreas Vetter wrote:
Hi, since os-update is useful on Leap: Are you willing to submit it to Leap/Backports 15.5? Or would you mind, if I do it and add it as a feature in https://code.opensuse.org/leap/features ?
There was an old SR, but with a on Leap not working version of os-update. I have updated that. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Great. Thank you :-) Mit freundlichen Grüßen Andreas Vetter -------- Ursprüngliche Nachricht -------- Von: Thorsten Kukuk <kukuk@suse.de> Datum: 09.12.22 11:24 (GMT+01:00) An: Andreas Vetter <vetter@physik.uni-wuerzburg.de> Cc: factory@lists.opensuse.org Betreff: Re: New package: os-update Hi, On Fri, Dec 09, Andreas Vetter wrote:
Hi, since os-update is useful on Leap: Are you willing to submit it to Leap/Backports 15.5? Or would you mind, if I do it and add it as a feature in https://code.opensuse.org/leap/features ?
There was an old SR, but with a on Leap not working version of os-update. I have updated that. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
participants (3)
-
Andreas Vetter -
Jacob Michalskie -
Thorsten Kukuk