* bug#36659: There should be an unattended upgrades service @ 2019-07-15 10:17 pelzflorian (Florian Pelz) 2019-07-16 7:29 ` Matthew Brooks 2020-11-30 16:40 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 0 siblings, 2 replies; 7+ messages in thread From: pelzflorian (Florian Pelz) @ 2019-07-15 10:17 UTC (permalink / raw) To: 36659 Some users (want to) forget about regularly upgrading Guix System. There should be an unattended upgrades service. Some requirements come to mind for its configuration: 1) Some users may want their unattended upgrades service to take care just of reconfiguring from a recent checkout and some may want it to take care of updating users’ ~/.config/guix/current and ~/guix-profile profiles. 2) Maybe there should be libnotify integration for unattended upgrades if the user uses a desktop environment. 3) Updates may fail if there is no internet connection. Some users may *not* want upgrades on metered internet connections. Some users may *not* want upgrades over untrusted connections. This report is a followup to Ludo’s proposal at <https://issues.guix.gnu.org/issue/36636> to add such a service and add it to %desktop-services, making it the default setting. Such a change in defaults could be a bad surprise for some users and should not go unnoticed, I think. Regards, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-15 10:17 bug#36659: There should be an unattended upgrades service pelzflorian (Florian Pelz) @ 2019-07-16 7:29 ` Matthew Brooks 2019-07-16 12:46 ` Ricardo Wurmus 2019-07-16 14:04 ` pelzflorian (Florian Pelz) 2020-11-30 16:40 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 1 sibling, 2 replies; 7+ messages in thread From: Matthew Brooks @ 2019-07-16 7:29 UTC (permalink / raw) To: 36659 If an automatic updater is included by default (which I think would be a rather bad idea), it absolutely needs to be very easy for a user to disable. GuixSD gives users a hell of a lot more control over the system and software and such than most other operating systems do, and that's a great strength. Leaving all those decisions in the hands of an automatic updating algorithm seems like a great way to discourage users from actually using the full power of the system and instead treat guix as just another generic distribution that decides things for the users instead of letting them decide for themselves. Especially since guix already lets the user know if it's older than about a week or so, which is probably plenty for anything other than the most demanding of security needs. Further, an automatic upgrade service wouldn't really add anything useful, since cron jobs and scripts can already be used to automate upgrading if one so desires. Additionally, anyone who is able to install the system to begin with would easily be able to set up such a cron job if they wish, since creating the system config file takes more work than making a small bash script with the few commands needed to update everything. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-16 7:29 ` Matthew Brooks @ 2019-07-16 12:46 ` Ricardo Wurmus 2019-07-16 13:23 ` Arne Babenhauserheide 2019-07-16 14:04 ` pelzflorian (Florian Pelz) 1 sibling, 1 reply; 7+ messages in thread From: Ricardo Wurmus @ 2019-07-16 12:46 UTC (permalink / raw) To: Matthew Brooks; +Cc: 36659 Hi Matthew, > If an automatic updater is included by default (which I think would be > a rather bad idea), it absolutely needs to be very easy for a user to > disable. Of course. It would be as simple as removing a service from the list of default system services in the operating system configuration. > Further, an automatic upgrade service wouldn't really add anything > useful, since cron jobs and scripts can already be used to automate > upgrading if one so desires. I disagree. We provide a whole lot of services that aren’t strictly necessary in order to satisfy what we think are reasonable user expectations. An upgrade service that’s easily removed or configured seems nicer to me than having to muck about with cron jobs and scripts by myself. -- Ricardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-16 12:46 ` Ricardo Wurmus @ 2019-07-16 13:23 ` Arne Babenhauserheide 2019-07-24 16:35 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Arne Babenhauserheide @ 2019-07-16 13:23 UTC (permalink / raw) To: 36659 [-- Attachment #1: Type: text/plain, Size: 1274 bytes --] Ricardo Wurmus <rekado@elephly.net> writes: >> Further, an automatic upgrade service wouldn't really add anything >> useful, since cron jobs and scripts can already be used to automate >> upgrading if one so desires. > > I disagree. We provide a whole lot of services that aren’t strictly > necessary in order to satisfy what we think are reasonable user > expectations. An upgrade service that’s easily removed or configured > seems nicer to me than having to muck about with cron jobs and scripts > by myself. I would most of all like to see a CVE-checking service that tells me about security updates. Sometimes I’ll ignore updates for a few weeks because I have a setup that absolutely must keep working, because I could not even afford half an hour of brokenness, but I must still do security updates, and I would like Guix to tell me about those. Also it would be interesting to have an auto-update service that only updates /run/current-system That way users would only have to worry about their personal installations, but not about the underlying base-system. I think there are many users who would be most happy if they never had to sudo. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1076 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-16 13:23 ` Arne Babenhauserheide @ 2019-07-24 16:35 ` Ludovic Courtès 0 siblings, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2019-07-24 16:35 UTC (permalink / raw) To: Arne Babenhauserheide; +Cc: 36659 Hi, Arne Babenhauserheide <arne_bab@web.de> skribis: > Also it would be interesting to have an auto-update service that only > updates /run/current-system Yes, that’s what we’re talking about here, or at least what I had in mind. :-) Ludo’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-16 7:29 ` Matthew Brooks 2019-07-16 12:46 ` Ricardo Wurmus @ 2019-07-16 14:04 ` pelzflorian (Florian Pelz) 1 sibling, 0 replies; 7+ messages in thread From: pelzflorian (Florian Pelz) @ 2019-07-16 14:04 UTC (permalink / raw) To: Matthew Brooks, Arne Babenhauserheide, Ricardo Wurmus; +Cc: 36659 This is just my opinions/ideas: On Tue, Jul 16, 2019 at 02:29:07AM -0500, Matthew Brooks wrote: > If an automatic updater is included by default (which I think would > be a rather bad idea), it absolutely needs to be very easy for a > user to disable. Guix System should target non-power users too. It is already much easier to install packages and services than in Debian, especially if no sudo were ever needed as Arne wrote in his reply. Perhaps if the unattended upgrades service were not included in %desktop-services but selectable in the Guix System graphical installer and selected by default, users would feel more in control and existing users would not be surprised. If unattended-upgrades-service-type checked with NetworkManager for metered connections *and* if substitutes are available *and* the power user can configure a blacklist/whitelist of trusted connections, the only downside I see is less internet bandwidth during upgrades and slightly more battery drain, but security is more important and the more responsible default. Maybe make it configurable if upgrades should be performed when on battery. Maybe users could stop an upgrade via libnotify notification? On Tue, Jul 16, 2019 at 03:23:35PM +0200, Arne Babenhauserheide wrote: > I would most of all like to see a CVE-checking service that tells me > about security updates. Sometimes I’ll ignore updates for a few weeks > because I have a setup that absolutely must keep working, because I > could not even afford half an hour of brokenness, but I must still do > security updates, and I would like Guix to tell me about those. > A CVE notification service would be right for %desktop-services, I think. Regards, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#36659: There should be an unattended upgrades service 2019-07-15 10:17 bug#36659: There should be an unattended upgrades service pelzflorian (Florian Pelz) 2019-07-16 7:29 ` Matthew Brooks @ 2020-11-30 16:40 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 1 sibling, 0 replies; 7+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2020-11-30 16:40 UTC (permalink / raw) To: 36659-done [-- Attachment #1: Type: text/plain, Size: 204 bytes --] One was added by Ludo' in commit 79501f26ab6d82c0256ff786a5dfb0000b52ccd3. The unrelated (CVE) or enhancement (NM integration) suggestions upthread are separate topics. Closing! Kind regards, T G-R [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-30 16:41 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-07-15 10:17 bug#36659: There should be an unattended upgrades service pelzflorian (Florian Pelz) 2019-07-16 7:29 ` Matthew Brooks 2019-07-16 12:46 ` Ricardo Wurmus 2019-07-16 13:23 ` Arne Babenhauserheide 2019-07-24 16:35 ` Ludovic Courtès 2019-07-16 14:04 ` pelzflorian (Florian Pelz) 2020-11-30 16:40 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).