Release highlights
- VM licensing: optional new license type specific for virtual machines
- database schema check in the initscripts
- better initscripts
- automatic activity status update in the UI using ajax
- new alerts: license overflow and package reporting errors
- ajax-style alert notification in the UI
Read on for details.
Upgrading
Please make sure you have backed up the database and all the Landscape config files before proceeding with the upgrade.
Upgrading from appliance (KVM) version
NOTE: This is not supported by the packaged version. Please contact Canonical support for assistance in doing this upgrade.
Quickstart upgrade
In general, the quickstart upgrade works just fine from either LDS 1.6 or LDS 11.03. You may see some warnings about patch errors, but these are accounted for, and if there was a real patch problem, the service start at the end of the upgrade will tell you.
Nonquickstart upgrade from 11.03
The only changes required by this upgrade are schema changes, both to Landscape and to the Clouddeck databases. If you have UPGRADE_SCHEMA set to “yes” in /etc/default/landscape-server, then only the clouddeck schema needs to be updated manually.
- to upgrade the Landscape schema, run this command after the landscape-server package upgrade:
sudo setup-landscape-server
- to upgrade the clouddeck schema, run this command after the clouddeck package upgrade:
sudo clouddeck-schema /etc/clouddeck/stores.cfg
Both commands will only take a few seconds in this upgrade.
Nonquickstart upgrade from 1.6
This upgrade is not trivial. Please follow the steps described in the [[LDS/NonQuickstartUpgrade|1.6 to 11.03 nonquickstart upgrade]].
VM Features
This release of LDS introduces a new license type called “VMFeatures”. It is backwards compatible with previous LDS release. If purchased, this new license can be used exclusively by virtual machines, including cloud instances. We currently detect vmware, xen and kvm. The use of this feature requires landscape-client 11.07.1.1 or higher.
If you register a virtual machine with Landscape, and you have seats available in the VMFeatures license, the computer will use one of these seats. If VMFeatures is not available, or doesn’t have enough seats, then a regular Full seat will be used.
Bare metal machines cannot use VMFeatures seats: they can only use the regular Full license seats. Virtual machines, on the other hand, can use either.
If you upgrade to the new license format, however, DO NOT DOWNGRADE BACK TO THE OLD ONE. Doing so will remove all existing computers from a license and you will need to license them all again by selecting them and going to the Info page and selecting a suitable license.
Known Issues
VMFeatures requires new registration
To use a VMFeatures seat, the machine (VM) has to be registered again as this information is only reported at registration time. If it’s an existing VM in Landscape, it will need to be removed and registered again, or just registered again. Registering in place of an existing Landscape computer won’t work for this feature.
Warnings about transaction module
Some initscripts and the quickstart upgrade will report a warning about the transaction module. This is benign and can be ignored.
Ignoring patch error during LDS upgrades
During the LDS upgrade, you may see one or more messages saying an exception during the application of database schema changes was ignored. These are expected in some cases, and a confirmation that everything is OK can be seen later on when the services are started. We now check for the correct database schema before starting the services, so if they start, then all patches were applied correctly.
No “Ubuntu” release in the cloud page, only “Other”
The cloud page needs to know the AMI for each Ubuntu release. This data is filled in by a cron job (“maintenance”) that runs once a day and, among other things, checks for new AMIs on uec-images.ubuntu.com.
To populate that information right after installation, just run the following command:
sudo -u landscape /opt/canonical/landscape/scripts/maintenance_wrapper.sh
It needs a network connection, but what it downloads is very small and it should take just a few seconds. It can be run while all services are up, no problems with that.
Custom Natty AMIs, or in Eucalyptus, won’t register
The only Natty cloud images that will register automatically when launched from the Landscape UI are the official Ubuntu ones in EC2, and those will still need the database query shown earlier. Instances started from custom EC2 Natty images, or using Eucalyptus, won’t register with Landscape automatically.
Natty cloud images won’t register with the server
Due to a change in the way that Natty images in the cloud bootstrap their Landscape registration, a small tweak is needed in the database to make this registration work. Connect to the database server either as a super user or as the landscape_maintenance user and issue an UPDATE command like the following:
landscape-standalone-main=# BEGIN;
BEGIN
landscape-standalone-main=# UPDATE ec2_current_image SET cloud_init_supported # true WHERE ubuntu_release_name # 'natty';
UPDATE 20
landscape-standalone-main=# COMMIT;
COMMIT
Package availability in the repository
The package repository we use to release the LDS packages will only carry the latest version at any given time. If you need to have one of the previous versions, please contact Canonical Support.
Creating cloud keypair with chrome/chromium
When a cloud ssh key pair is created with chrome or chromium, the javascript on that page crashes right afterwards and the page basically stops working. To workaround the issue, just reload the page.
Incorrect feedback link in account expired page
When an LDS license expires while the services will running, any access to the LDS application will redirect the user to an “Account expired” page. This page has an incorrect link for sending feedback. Please contact support instead using either the hosted version of Landscape (https://landscape.canonical.com) or the phone numbers that were given to you.
Package upgrade asks about config file
During a package upgrade, the process will stop and ask what it should do with one or more modified config files. For example:
Configuration file `/etc/landscape/service.conf'
> Modified (by you or by a script) since installation.
> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** service.conf (Y/I/N/O/D/Z) [default=N] ?
This is unfortunately expected. You should answer “N” here, or else the configuration file will be replaced and you will need to fix it manually.
After upgrades, /var/lib/landscape/hash-id-databases contains double the data
That directory, after an upgrade, will contain both the generic files starting with uuid_ and the “real” files, used by the server, with their names starting with the real uuid. The only harm here is using more disk space than necessary.
NOTE: ‘’'It is imperative that the files starting with the real uuid are not changed in any way! In other words, do not attempt to overwrite them with the newer unrenamed files coming from the updated package! Doing so will completely mess up the package information and will require all clients to register again!