Release Notes

Release notes for version

This document contains the release notes for the Landscape Dedicated Server (LDS) software version Below you will find a list of changes, followed by a more detailed explanation.


These are the highlights for the version of the LDS package:

  • First packaged version in the Debian format. The old kvm appliance does not exist anymore.
  • New quickstart package, to make deployment for simple scenarios much easier.
  • The service now needs a license file in order to start.
  • New theme.
  • New configuration mechanism, allowing for an easier split of services among different machines.
  • Schema can be automatically upgraded during a package upgrade.
  • Support for new Amazon Tokyo region

Read on for details.


NOTE: ‘’‘There is no automated way to upgrade from the LDS appliance (using KVM) to the packaged format. Please contact Canonical for assistance in this upgrade.’’’

New Theme

The new theme is not enabled by default, but can be selected by clicking on the “Try our new look!” link on the top right of the page.

If for some reason you want the old theme back, there is a “back to old look” link at the bottom of the page. If you decide to switch back, please tell us the reason so we can improve this theme. Eventually it will become the default one so we really want to get it just right.


This is the first release of LDS as Debian Packages. These are the packages that compose LDS from now on:

  • landscape-server: package containing all the LDS code and services, geared towards more robusts installations. All the configuration is left to the administrator, including the SQL database, and the services can be easily split among different machines to compose a more robust and scalable deployment.
  • landscape-server-quickstart: this package does it all. It installs and configures LDS with all the services, including the SQL database. All that is left for the administrator is to provide the SSL certificates and install the LDS license file, which enables the service.
    The packages are distributed via a private PPA, and licensees will receive instructions on how to sign up.

For an example deployment using two machines (one application server and one database server), please see the [[LDS/RecommendedDeployment|recommended deployment document]].


The landscape-server package allows for some interesting deployment scenarios. By configuring the /etc/default/landscape-server package, you can select which services to start on this machine. This allows the administrator do deploy the landscape-related services in more than one machine, obtaining a better performance and overall availability.

The main Landscape configuration file is now also placed in the /etc/landscape directory. Administrators shouldn’t need to edit this file directly, though.

Automatic schema upgrades

A schema upgrade is when a new version of Landscape requires changes in the database schema, such as adding a new column to a table, or changing a piece of data somehow. Some things to know about schema upgrades:

  • they can take from a few seconds to several minutes, depending on the hardware and the changes involved;
  • if a new version of Landscape is started and it detects that the database schema is old, it will quit with an error message in the service logs.
    That being said, the schema upgrade can be automatic or manual. It is ‘’‘automatic’’’:
  • when the landscape-server-quickstart package is being upgraded. This package ‘’‘always’’’ performs the schema upgrade as a post installation step.
  • if the landscape-server package is being upgraded and UPGRADE_SCHEMA is set to yes (default is no).

NOTE: ‘’‘Make sure you backup your database before upgrading the Landscape packages with the automatic schema upgrade enabled!’’’

If you have a deployment layout with more than one application server machine, please make sure to stop all Landscape services on all machines before upgrading the package installed on each one.

Manual schema upgrade

If you didn’t change the default setting UPGRADE_SCHEMA=no in /etc/default/landscape-server, then when upgrading the landscape-server package no schema upgrade will be attempted. The package will try to restart the services after the package upgrade, however. If a schema upgrade was needed, the service start will fail.

In this case, you need to perform a manual schema upgrade:

  • stop all landscape-related services
  • backup your database
  • upgrade the landscape-server package
  • stop all landscape-related services again in case they were started by the package upgrade
  • run the setup-landscape-server script as root:
sudo setup-landscape-server

This script will, among other things, do a database schema upgrade if needed.

  • restart all landscape-related services

Known Issues

These are the currently known issues with this version.

Services fail to start with no license, or expired license

If the license (/etc/landscape/license.txt) file has expired, does not exist or is otherwise invalid, the Landscape services won’t start and there will be no indication about the error at the console or in the web interface.

The only place the proper error is shown is in the Landscape logs in /var/log/landscape/landscape.log.

No warning about expired license in the Web UI

If the license of a running LDS installation expires, there won’t be any warning or indication about this in the Web user interface. It will continue working normally, but the managed machines won’t be able to exchange messages anymore with the server.

The server log /var/log/landscape/message_server.log will contain lines such as these:

2011-02-03T00:00:04 WARNING root Computer 2 has no valid licenses.
2011-02-03T00:06:25 WARNING root Computer 1 has no valid licenses.

If you go to a computer’s info page, and click on the edit link, you will also see a hint in the License section that it has expired.

If the service is shutdown (for example, for a restart), then it won’t come up again because of the expired license.

Public key used for signing was removed (client was purged)

If landscape-client is installed on the same machine as landscape-server, and landscape-client is purged, the landscape services won’t start again because of the missing Landscape public key (bug #686569).

The fix is to import the key again, as shown below (just paste the BEGIN/END block into the terminal after the --import command and hit CTRL-D):

root@ubuntu:~# mkdir -m 0700 /var/lib/landscape/.gnupg
root@ubuntu:~# GNUPGHOME=/var/lib/landscape/.gnupg gpg --import
gpg: keyring `/var/lib/landscape/.gnupg/secring.gpg' created
gpg: keyring `/var/lib/landscape/.gnupg/pubring.gpg' created
Version: GnuPG v1.4.10 (GNU/Linux)

gpg: /var/lib/landscape/.gnupg/trustdb.gpg: trustdb created
gpg: key C5C88EE6: public key "Landscape License Signing Key <>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

root@ubuntu:~# chown landscape:landscape -R /var/lib/landscape/.gnupg

Purge + reinstall doesn’t work

If landscape-server-quickstart is purged and reinstalled, it won’t work anymore because the database wasn’t touched by the purge. You will see an error similar to the following:

10.12.07 12:32:10 - INFO - Landscape server setup - Setting up Apache SSL configuration ...
apache2: Could not reliably determine the server's fully qualified domain name, using for ServerName
[Tue Dec 07 12:32:10 2010] [warn] NameVirtualHost *:80 has no VirtualHosts
2010.12.07 12:32:10 - INFO - Landscape server setup - Configuring RabbitMQ for Landscape ...
2010.12.07 12:32:11 - INFO - Landscape server setup - Configuring PostgreSQL for Landscape
2010.12.07 12:32:11 - INFO - Landscape server setup - Bootstrapping server.conf using psql ...
could not change directory to "/root"
2010.12.07 12:32:11 - INFO - Landscape server setup - Checking Landscape databases ...
could not change directory to "/root"
2010.12.07 12:32:11 - INFO - Landscape server setup - Setting up database configuration ...
2010.12.07 12:32:11 - ERROR - Landscape server setup - No option 'password' in section: 'database'

In this case, /etc/landscape/server.conf will be empty, with no values, only keys.

The fix is to drop all postgresql users prefixed with “landscape” and also all Landscape databases prefixed with “landscape-standalone”.


root@ubuntu:~# su - postgres
postgres@ubuntu:~$ psql postgres
psql (8.4.5)
Type "help" for help.
postgres=# DELETE FROM pg_authid WHERE rolname IN ('landscape_maintenance','landscape_superuser','landscape');

Now to drop the LDS databases:

postgres@ubuntu:~$ for db in $(psql -l | grep landscape-standalone-|awk '{print $1}'); do dropdb $n; done

If you get an ImportError in postinst

So far, we seem to be doing fine, but it’s possible that a new python dependency could reintroduce the problem of having the postinst script of landscape-server or landscape-server-quickstart fail with an import error. If that happens, running the installation again (apt-get -f <package>) should work.

Initscripts always say “OK” for start action

The initscripts can’t tell for sure if the service started properly or not. That’s mostly due to the use of the --background option. So, don’t rely solely on the output of each initscript to determine if a service is running or not: check the ps output instead

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

To populate that information right after installation, just run the following command:

sudo -u landscape /opt/canonical/landscape/scripts/

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.

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!

Package upgrade asks about config file

During a package upgrade, the process will stop and ask what it should do with a modified config file:

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.

Apache’s default vhost overriding landscape’s

The apache2 package installs a default vhost with no ServerName. This makes apache use the FQDN of the machine as ServerName upon startup.

If this is the same hostname chosen for the LDS site, then the Apache default one will override ours. The main symptom is that accessing http://servername/ won’t redirect you to https and the Landscape front page, but will instead show a plain “It worked!” apache page or something similar.

One alternative here is to just disable the default vhost:

sudo a2dissite default
sudo /etc/init.d/apache2 restart

Sample scenario where the problem will occur:

  • the machine chosen to host LDS is called
  • that’s the hostname of the machine, and also how it is reached via the local network
  • you install LDS on it, and the SSL certificate to be used have in the common name field
  • in the end, there are two files in /etc/apache2/sites-enabled: default and
  • when accessing, you will be greeted by a simple Apache page saying something like “It worked!”, instead of LDS via https. Accessing, however, works.