| 2013-08-05 09:11:31 |
Alexander List |
bug |
|
|
added bug |
| 2013-08-05 09:12:02 |
Alexander List |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2013-08-06 07:37:11 |
Dean Henrichsmeyer |
landscape: milestone |
|
later |
|
| 2015-06-08 02:01:55 |
Paul Collins |
removed subscriber Alexander List |
|
|
|
| 2016-01-14 19:56:43 |
Benji York |
landscape: status |
New |
Triaged |
|
| 2016-04-13 14:37:43 |
Adam Collard |
tags |
|
is |
|
| 2016-06-22 14:39:41 |
Adam Collard |
landscape: assignee |
|
David Britton (davidpbritton) |
|
| 2016-07-13 10:35:41 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2017-01-23 23:07:04 |
Junien F |
bug |
|
|
added subscriber Junien Fridrick |
| 2017-01-25 11:55:00 |
Vincent Ladeuil |
bug |
|
|
added subscriber Vincent Ladeuil |
| 2017-03-01 01:51:58 |
Paul Gear |
tags |
is |
canonical-is is |
|
| 2017-03-03 15:47:09 |
Данило Шеган |
landscape: assignee |
David Britton (davidpbritton) |
Данило Шеган (danilo) |
|
| 2017-04-25 13:37:18 |
David Britton |
landscape: assignee |
Данило Шеган (danilo) |
|
|
| 2017-04-25 14:21:00 |
Uros Jovanovic |
landscape: status |
Triaged |
Won't Fix |
|
| 2017-04-26 05:32:47 |
Junien F |
landscape: status |
Won't Fix |
Triaged |
|
| 2017-05-18 03:23:07 |
Barry Price |
removed subscriber Vincent Ladeuil |
|
|
|
| 2017-06-05 14:05:52 |
Simon Poirier |
landscape: assignee |
|
Simon Poirier (simpoir) |
|
| 2017-06-05 14:05:55 |
Simon Poirier |
landscape: status |
Triaged |
In Progress |
|
| 2017-07-21 22:21:54 |
🤖 Landscape Builder |
landscape: status |
In Progress |
Fix Committed |
|
| 2017-08-07 15:00:48 |
Daniel Manrique |
bug |
|
|
added subscriber Daniel Manrique |
| 2017-10-11 14:14:51 |
Tom Haddon |
removed subscriber The Canonical Sysadmins |
|
|
|
| 2017-11-10 15:44:45 |
Andreas Hasenack |
information type |
Proprietary |
Public |
|
| 2017-11-10 15:45:12 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu) |
|
| 2017-11-10 15:45:34 |
Andreas Hasenack |
bug task added |
|
landscape-client |
|
| 2017-11-10 15:46:44 |
Andreas Hasenack |
landscape-client: status |
New |
Fix Committed |
|
| 2017-11-10 15:46:52 |
Andreas Hasenack |
landscape-client: assignee |
|
Simon Poirier (simpoir) |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Xenial) |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Trusty) |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Artful |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Artful) |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-11-10 15:50:22 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Zesty) |
|
| 2017-11-10 16:12:19 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/333548 |
|
| 2017-11-10 17:17:50 |
Andreas Hasenack |
landscape-client (Ubuntu): status |
New |
In Progress |
|
| 2017-11-10 17:17:52 |
Andreas Hasenack |
landscape-client (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-20 17:21:35 |
Launchpad Janitor |
landscape-client (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-11-23 18:11:21 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334203 |
|
| 2017-11-23 18:11:33 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334204 |
|
| 2017-11-23 18:11:45 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334205 |
|
| 2017-11-23 18:11:56 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334206 |
|
| 2017-11-23 18:35:52 |
Andreas Hasenack |
description |
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 18:41:50 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 18:59:48 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 19:01:14 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 19:02:26 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 19:04:21 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 19:12:41 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t "test-sru-1208393" --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min
* keep tailing -f /var/log/landscape/package-reporter.log and look for the message where it says it's reporting autoremovable packages:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* On the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding with) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t test-sru-1208393 --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* select the computer, go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min or even more on artful because staging does not have a hash-id cache for artful.
* keep tailing -f /var/log/landscape/package-reporter.log on the client and look for multiple messages where it says it's reporting autoremovable packages. Here is one example:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* Once all packages have been reported to the server (no more "changes in known packages on the client log), on the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
It's an opt-in feature, so it won't affect people who do not enable it in the auto-upgrade profiles.
[Other Info]
This is technically a new feature, but it has been one of the most requested ones.
As of the time of this writing, there is no public landscape server (apart from staging) which has support for this feature. But it's good to have the client out there for when the server is upgraded.
A new client talking to an old server won't cause problems. The server will simply discard the extra autoremovable package list.
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-23 19:25:43 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component.
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding with) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t test-sru-1208393 --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* select the computer, go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min or even more on artful because staging does not have a hash-id cache for artful.
* keep tailing -f /var/log/landscape/package-reporter.log on the client and look for multiple messages where it says it's reporting autoremovable packages. Here is one example:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* Once all packages have been reported to the server (no more "changes in known packages on the client log), on the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
It's an opt-in feature, so it won't affect people who do not enable it in the auto-upgrade profiles.
[Other Info]
This is technically a new feature, but it has been one of the most requested ones.
As of the time of this writing, there is no public landscape server (apart from staging) which has support for this feature. But it's good to have the client out there for when the server is upgraded.
A new client talking to an old server won't cause problems. The server will simply discard the extra autoremovable package list.
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component, or from staging.landscape.canonical.com as soon as it also gets this client update (yes, the client update is needed on the server as well for this feature to work).
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding with) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t test-sru-1208393 --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* select the computer, go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min or even more on artful because staging does not have a hash-id cache for artful.
* keep tailing -f /var/log/landscape/package-reporter.log on the client and look for multiple messages where it says it's reporting autoremovable packages. Here is one example:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* Once all packages have been reported to the server (no more "changes in known packages on the client log), on the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
It's an opt-in feature, so it won't affect people who do not enable it in the auto-upgrade profiles.
[Other Info]
This is technically a new feature, but it has been one of the most requested ones.
As of the time of this writing, there is no public landscape server (apart from staging) which has support for this feature. But it's good to have the client out there for when the server is upgraded.
A new client talking to an old server won't cause problems. The server will simply discard the extra autoremovable package list.
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-24 12:46:23 |
Andreas Hasenack |
description |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component, or from staging.landscape.canonical.com as soon as it also gets this client update (yes, the client update is needed on the server as well for this feature to work).
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding with) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t test-sru-1208393 --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* select the computer, go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min or even more on artful because staging does not have a hash-id cache for artful.
* keep tailing -f /var/log/landscape/package-reporter.log on the client and look for multiple messages where it says it's reporting autoremovable packages. Here is one example:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* Once all packages have been reported to the server (no more "changes in known packages on the client log), on the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
It's an opt-in feature, so it won't affect people who do not enable it in the auto-upgrade profiles.
[Other Info]
This is technically a new feature, but it has been one of the most requested ones.
As of the time of this writing, there is no public landscape server (apart from staging) which has support for this feature. But it's good to have the client out there for when the server is upgraded.
A new client talking to an old server won't cause problems. The server will simply discard the extra autoremovable package list.
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
[Impact]
It is good practice to remove unneeded packages/software from a machine. On the shell, this can be achieved by using "apt autoremove". There is no way to do it via landscape.
The lack of this option can lead to a full /boot partitions, for example, by accumulating kernel packages that are no longer used.
The fix in Landscape is a new checkbox option in the existing auto-upgrade profile feature. If checked, whenever an auto-upgrade profile is applied to a computer, meaning, upgrades will be done, the client will also do the equivalent of "apt autoremove", thus removing packages that are no longer used.
The caveat is that, at the time of this writing, the server portion of this feature is not yet available, so it can only be tested with a trunk deployment of the server component, or from staging.landscape.canonical.com as soon as it also gets this client update (yes, the client update is needed on the server as well for this feature to work).
[Test Case]
* get a test account on staging.landscape.canonical.com. That deployment has autoremove support. You may email the address in the #landscape topic in the internal canonical irc channel to request such an account.
* Login to https://staging.landscape.canonical.com and create an autoupgrade profile, configure it to apply to computers with the tag "autoupgraderemove", and make sure to tick the "autoremove packages" option. Also configure it to apply to all days of the week (or at least "today") and at every hour at XX minutes. You will change XX later.
* create an ubuntu VM or LXD (easier) running the release you are testing. On it, make sure there are upgrades available. Do not upgrade the packages. If there are no available upgrades (i.e., the image you picked to deploy this VM or LXD was up-to-date), inspect packages you have installed with apt-cache policy and try to downgrade some. You need at least one upgrade available.
* install devscripts, and then remove it:
- sudo apt install devscripts
- sudo apt purge devscripts
That should trigger a lot of autoremovable possibilities. Confirm by running (but not proceeding with) "apt autoremove"
* install landscape-client from proposed and register it against staging. Something like:
sudo landscape-config --silent -a <your-account-name> -t test-sru-1208393 --script-users ALL --include-manager-plugins ScriptExecution -u https://staging.landscape.canonical.com/message-system --ping-url http://staging.landscape.canonical.com/ping
* go to the staging.landscape.canonical.com pending computers page and accept this computer
* select the computer, go to the packages page and wait for this computer to report all packages and available upgrades. This could take about 15min or even more on artful because staging does not have a hash-id cache for artful.
* keep tailing -f /var/log/landscape/package-reporter.log on the client and look for multiple messages where it says it's reporting autoremovable packages. Here is one example:
2017-11-13 13:49:22,220 INFO [MainThread] Queuing message with changes in known packages: 421 installed, 62279 available, 44 available upgrades, 0 locked, 1 autoremovable, 0 not installed, 0 not available, 0 not available upgrades, 0 not locked, 0 not autoremovable.
* That confirms the client is reporting the autoremovable packages.
* Once all packages have been reported to the server (no more "changes in known packages on the client log), on the server, add the tag "autoupgraderemove" to this registered computer.
* Edit the autoupgrade profile you created before and make sure it is configured to kick in in the next 5 minutes. Change its configuration if needed.
* Wait 5-10min. You should eventually see an activity that will upgrade packages on this computer, as well as autoremove others.
* Once the activity is finished, confirm that "apt autoremove" on the computer no longer has packages to remove.
[Regression Potential]
This feature relies on "apt autoremove" working correctly and not doing silly things, like removing your running kernel, or bash, or something else that's essential.
It's an opt-in feature, so it won't affect people who do not enable it in the auto-upgrade profiles.
[Other Info]
This is technically a new feature, but it has been one of the most requested ones.
As of the time of this writing, there is no public landscape server (apart from staging) which has support for this feature. But it's good to have the client out there for when the server is upgraded.
A new client talking to an old server won't cause problems. The server will simply discard the extra autoremovable package list.
This PPA has packages built from these branches:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
They are using a ~ppaN suffix.
--- Original Description below ---
Canonical IS have moved software updates almost entirely to Landscape.
Apart from updating software packages, it is also good practice to remove unneeded software.
On the shell, this can be achieved using "apt-get autoremove"
It would be desirable to have this functionality available in Landscape. |
|
| 2017-11-24 18:19:32 |
Andreas Hasenack |
landscape-client (Ubuntu Trusty): status |
New |
In Progress |
|
| 2017-11-24 18:19:35 |
Andreas Hasenack |
landscape-client (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-11-24 18:19:38 |
Andreas Hasenack |
landscape-client (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-11-24 18:19:42 |
Andreas Hasenack |
landscape-client (Ubuntu Artful): status |
New |
In Progress |
|
| 2017-11-24 18:19:45 |
Andreas Hasenack |
landscape-client (Ubuntu Trusty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:19:48 |
Andreas Hasenack |
landscape-client (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:19:51 |
Andreas Hasenack |
landscape-client (Ubuntu Zesty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:19:53 |
Andreas Hasenack |
landscape-client (Ubuntu Artful): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-27 16:17:08 |
Łukasz Zemczak |
landscape-client (Ubuntu Artful): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:17:10 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-11-27 16:17:12 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2017-11-27 16:17:17 |
Łukasz Zemczak |
tags |
canonical-is is |
canonical-is is verification-needed verification-needed-artful |
|
| 2017-11-27 16:27:02 |
Łukasz Zemczak |
landscape-client (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:27:08 |
Łukasz Zemczak |
tags |
canonical-is is verification-needed verification-needed-artful |
canonical-is is verification-needed verification-needed-artful verification-needed-zesty |
|
| 2017-11-27 16:32:07 |
Łukasz Zemczak |
landscape-client (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:32:15 |
Łukasz Zemczak |
tags |
canonical-is is verification-needed verification-needed-artful verification-needed-zesty |
canonical-is is verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty |
|
| 2017-11-27 16:38:28 |
Łukasz Zemczak |
landscape-client (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:38:34 |
Łukasz Zemczak |
tags |
canonical-is is verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty |
canonical-is is verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty |
|
| 2017-12-01 21:16:39 |
Mathew Hodson |
landscape-client (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2017-12-01 21:16:42 |
Mathew Hodson |
landscape-client (Ubuntu Trusty): importance |
Undecided |
Wishlist |
|
| 2017-12-01 21:16:44 |
Mathew Hodson |
landscape-client (Ubuntu Xenial): importance |
Undecided |
Wishlist |
|
| 2017-12-01 21:16:47 |
Mathew Hodson |
landscape-client (Ubuntu Zesty): importance |
Undecided |
Wishlist |
|
| 2017-12-01 21:16:50 |
Mathew Hodson |
landscape-client (Ubuntu Artful): importance |
Undecided |
Wishlist |
|
| 2017-12-05 13:02:16 |
Eric Desrochers |
tags |
canonical-is is verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty |
canonical-is is verification-done-artful verification-done-trusty verification-done-xenial verification-done-zesty verification-needed |
|
| 2017-12-05 15:18:11 |
Launchpad Janitor |
landscape-client (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:18:19 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-12-05 15:19:19 |
Launchpad Janitor |
landscape-client (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:20:11 |
Launchpad Janitor |
landscape-client (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:20:30 |
Launchpad Janitor |
landscape-client (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2018-04-18 15:12:51 |
Simon Poirier |
landscape: milestone |
later |
18.03 |
|
| 2019-03-20 17:08:25 |
Adam Collard |
landscape: status |
Fix Committed |
Fix Released |
|
