[feature request] ua status to provide unattended-upgrades status
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
'Unattended-
While we are currently working to modify our current onboarding and all documentation to do a better job at communicating it, we think it might be interesting to have 'unattended-
Example:
-------
$ ua status
SERVICE AVAILABLE DESCRIPTION
cc-eal no Common Criteria EAL2 Provisioning Packages
esm-apps yes UA Apps: Extended Security Maintenance
esm-infra yes UA Infra: Extended Security Maintenance
fips no NIST-certified FIPS modules
fips-updates no Uncertified security updates to FIPS modules
livepatch yes Canonical Livepatch service
=> unattended-upgrades yes Automatic installation of security upgrade
-------
description: | updated |
tags: | added: seg sts |
description: | updated |
summary: |
- [feature request] ua status to provide unattended-upgrade status + [feature request] ua status to provide unattended-upgrades status |
Hi Eric, I like the idea and have a few questions about how the client's behavior would interact with unattended- upgrades:
For example, how should the client determine what status to report? If the user has at least the default config enabled is that enough for the client to report yes? What if the security pocket gets disabled?
If a user wanted to disable unattended- upgrades, would the client remove the package?
If a user wanted to enable unattended- upgrades, would the client enable the default config?