Landscape 24.04 LTS Release Notes

Landscape 24.04 LTS Release Notes

Note: Landscape 24.04 LTS runs on Ubuntu 24.04 LTS Noble Numbat or 22.04 LTS Jammy Jellyfish.

Note: Database schema changes are required to upgrade to Landscape Server 24.04 LTS.

Highlights

  • New web portal: Use Landscape’s new, early-access web portal built with Canonical’s Vanilla Framework.

    Landscape 24.04 LTS new web portal

    This portal is available to self-hosted Landscape users. To access it, click Repositories from the header of the default web portal. The first time you use the portal, you may need to generate new API credentials to access the portal. For more information, see how to generate API credentials.

  • Web-based repository management: Manage and mirror your repositories locally with Landscape’s new web-based repository management. For more information, see how to manage and mirror repositories from the web portal and an explanation on repository mirroring.

  • REST API for self-hosted users: Use the new REST API that supports JSON Web Tokens for authentication. For more information, see how to make a REST API request and the available REST API endpoints.

  • Snap management: Manage snaps directly from the Landscape web portal.

  • Landscape Client - new features for Ubuntu Core users: The Landscape Client snap now includes additional features for Ubuntu Core users, such as remote script execution for snaps, user management on Core, and more. For more information, see the Landscape client snap how-to guides.

Additional updates

  • WSL: Update apache2 config template for Landscape Quickstart installations to use SSL/TLS on gRPC calls
  • Quickstart installation configures PostgreSQL max_connections and max_prepared_transactions

Bug fixes

  • #2055348: Potential arbitrary execution in expandvars
  • #2057976: Ubuntu Pro info is not sent on registration
  • #2043035: Landscape UI lag
  • #2059194: OIDC login not working, not producing any errors
  • #2062561: There are no APT sources configured in /etc/apt/sources.list or /etc/apt/sources.list.d.
  • In the legacy API, add access_group parameter to EditUpgradeProfile
  • Fixed the database object crossing thread boundaries in gRPC activities
  • Fix with bpickle to guard against negative string/bytestring lengths
  • Fixed errors on Ubuntu Pro tab for Windows machines
  • Fixed startup errors when Pro Licenses are the only Licenses
  • Memory-usage improvements for landscape-appserver service
  • Extra prevention against invitation hijacking
  • Language improvements around allowlists and blocklists
  • WSL instances are deleted when hosts stop reporting them
  • Distribution information is provided for pending Windows machines
3 Likes

Is there instructions on how to upgrade from 23 anywhere?

3 Likes

I just installed the new landscape version on a fresh 24.04 Ubuntu Server, however, it’s still showing the old web interface. What has to be done to enable the new interface?

Ok got it. Thanks to the quickstart package not working, I installed it via the manual install, which documentation isn’t updated yet for the new version. To get to the new interface, find the apache template in /opt/canonical/landscape/standalone/templates/apache_default.tmpl, copy that to /etc/apache2/sites-available/landscape.conf and edit to your needs. Then go to (landscape-url)/new_dashboard and you get the new ui.

1 Like

Hey @daniel_souvignier! I’m glad you figured out a way to access the new portal! :blush: You can also access the new web portal from the old portal by clicking Repositories in the header (top of the page). This text may change in the future, though - it says Repositories for now because that was a major new feature in the portal (web-based repository management).

Yes, figured that out already. Thing is, when I tried that after first manual install, it got back at me with a 404. That was because the instructions in the documentation at https://ubuntu.com/landscape/docs/manual-installation are not updated yet with the correct configuration in the RewriteCond Statements. That’s when I searched for the config template in the installation files. So please update your documentation as soon as possible.

1 Like

Hi!

Is there a upgrade guide from earlier version? or are they in the works?
@yanisa-hs will support for Ansible be implemented in the future?

@teddy-skarin-krim @alslinet We don’t have an upgrade guide just yet, although one is planned.

And I’m not aware of plans to support Ansible, but Landscape does have its own remote script execution feature, see how to manage scripts.

@daniel_souvignier Got it - I’ll check in with the team on that. Thank you for your feedback and providing all the details!

Regarding the remote script feature:
When you have a lot of VDI machines for example, users tend to break the VDI client and it would be nice to have a way to automatically detect and repair these types of issues. Scripts cant really do this today, as they need somone to initiate them, a recurrance setting or something similar for scripts would be great.

Many enterprise software vendors (Citrix for example) dont provide repos for their software so increasing the upload limit or adding a simple way to deploy dep packages from vendors would be useful. It would be nice if ubuntu provided some guidance on how to solve this and at least increased the upload limits for script attachments which just seems arbitrary to me, maybe it makes sence for the cloud solution, but to me it makes no sense to have this limitation for the self-hosted version.

Since we can sync only one pocket at a time. Is there any cron job available that loops through all your pockets?

3 Likes

thanks for this, I tried it out and cannot get it to work still 404. @yanisa-hs
Getting error:

https://host.com/new_dashboard request_id=c74933f4-224a-4226-bde3-add0765382ec
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/zope/app/publication/zopepublication.py”, line 395, in handleException
raise exc_info[1].with_traceback(exc_info[2])
File “/usr/lib/python3/dist-packages/zope/publisher/publish.py”, line 142, in publish
obj = request.traverse(obj)
File “/usr/lib/python3/dist-packages/zope/publisher/browser.py”, line 594, in traverse
ob = super().traverse(obj)
File “/usr/lib/python3/dist-packages/zope/publisher/http.py”, line 512, in traverse
ob = super().traverse(obj)
File “/usr/lib/python3/dist-packages/zope/publisher/base.py”, line 266, in traverse
obj = publication.traverseName(self, obj, entry_name)
File “/usr/lib/python3/dist-packages/zope/app/publication/zopepublication.py”, line 200, in traverseName
ob2 = adapter.publishTraverse(request, nm)
File “/opt/canonical/landscape/canonical/routes/publisher.py”, line 174, in publishTraverse
raise NotFound(self.context, name)
zope.publisher.interfaces.NotFound: Object: <canonical.landscape.model.root.landscape.LandscapeRoot object at 0x7fbcca2f45b0>, name: ‘new_dashboard’

Ansible requires SSH connectivity to deliver a playbook. If you would like to use Ansible, but do not have the ability to SSH into the device you wish configure with Ansible, Landscape is a suitable delivery mechanism for your playbook.

Landscape’s remote script execution capability accepts up to 5 attachments, and an Ansible Playbook can be an attachment. The script could be a 1-line command to run the Ansible playbook. You can’t use relative paths to find the attachments, but your script will correctly populate the $LANDSCAPE_ATTACHMENTS variable: $LANDSCAPE_ATTACHMENTS/name-of-your-file-here

Hi!
Yes, im fully aware of the script possibility, but to deliver a whole ansible playbook with roles isnt super efficient via landscape script(tried and tested), especially when you version control everything.

I think a ansible oriented/config management option would be quite powerfull given that one could use the inventory and tags/ from landscape to propagate into ansible jobs . :slight_smile:

I second that question. I could write a script doing that myself leveraging the legacy api using the landscape-api client package with the commands “sync-mirror-pocket”, waiting in the script for a respecting “get-event-log --limit 1” to return successfull. But that seems to be a bit hacky, there should be a better way of doing this.