Release Notes 11.03

Landscape Release notes
1

These are the release notes for Landscape Dedicated Server 11.03. Please read them carefully if you are considering installing LDS 11.03 or upgrading from a previous version.

Highlights

These are the highlights of version 11.03:

  • new cloud infrastructure: [[CloudDeck|Cloud Deck]]
  • new theme is now the default and only one
  • multiple instance support for app, msg and ping servers
  • password obfuscation for passwords in /etc/landscape/service.conf
  • several bug fixes

Read on for details.

Upgrade warnings

This section describes changes you should be aware of while deciding to upgrade your existing LDS installation.

This is a major new version, and as such the upgrade can be involved. Before doing the upgrade, please make sure that:

  • the landscape databases have been backed up
  • all landscape services, in ‘’‘all’’’ machines, have been stopped (the clients can remain running)

Upgrading from appliance (KVM) version

‘’‘This is not supported by the packaged version. Please contact Canonical support for assistance in doing this upgrade.’’’

Cloud upgrade

With the introduction of [[CloudDeck|Cloud Deck]] as our new cloud infrastructure, existing clouds that you had defined in Landscape prior to the upgrade won’t be visible anymore in Landscape after the upgrade. This means that existing:

  • keys
  • security groups
  • elastic IPs
  • EBS volumes
  • instances
    won’t be visible in Landscape and will need to be recreated using Landscape in order to be visible and usable. To avoid any confusion: Landscape won’t delete anything, it just won’t be visible. If you use another EC2 client and connect to the cloud directly, everything will still be there.

Do note that in the case of ssh keys, they will need to be replaced as there is no way currently to upload existing keys to Landscape/Cloud Deck. You also most likely won’t be getting the same Elastic IPs that you had before when you recreate them, so take that into account as well.

New cloud behaviour

From now on, Landscape will only display cloud related resources if they were created using Landscape. This means that, for example, if you create an instance using Amazon’s control panel, that instance won’t be listed when you view the same cloud in Landscape. The same goes for any other resource like ssh keys, security groups, elastic IPs, etc.

Upgrading with landscape-server

If you are using the landscape-server package and not landscape-server-quickstart, the upgrade procedure is quite involved and requires several steps, including manually creating new databases and database users and editing configuration files. Please see the upgrade instructions [[LDS/NonQuickstartUpgrade|here]].

Upgrading with landscape-server-quickstart

The quickstart package will handle all the details about the upgrade, including the setup of the new clouddeck databases and services and changes to existing configuration files (/etc/landscape/service.conf and /etc/default/landscape-server).

Port number changes

In order to support the feature where more than one app, msg or ping server can be started on the same machine, the base ports where the Landscape services listen on had to be changed. The quickstart package upgrade will handle these, but upgrades done with landscape-server only will have to be dealt with manually if you wish to take advantage of this new feature.

These are the new ports:

  • ping server: from 8082/tcp to ‘’‘8070/tcp’’’
  • message server: from 8081/tcp to ‘’‘8090/tcp’’’

Other changes

  • the default Apache vhost is disabled when landscape-server-quickstart is installed for the first time. Upgrades don’t touch the default vhost.
  • the maintenance cron job now uses https instead of http to contact uec-images.ubuntu.com, so you need to make sure that site can be reached on port 443/tcp.
  • stronger random passwords are chosen now by the quickstart package in first time installations.
  • existing passwords in /etc/landscape/service.conf will be obfuscated with base64 encoding and prefixed with b64: to indicate that.
  • new services: combo-loader listening on port 9070/tcp and API (this one not usable yet, but will be soon) listening on port 9080/tcp
  • new clouddeck services: service-api listening on port 8500/tcp and ec2-api listening on port 8600/tcp
  • the broker password (rabbitmq) is changed from the default value of landscape to a new random value during an upgrade
  • all passwords in /etc/landscape/service.conf will be obfuscated with base64 encoding during the upgrade

New features

  • Cloud Deck: please see [[CloudDeck|Cloud Deck]] and [[CloudDeckQuickStart|Cloud Deck Quickstart]] for details
  • EC2-compatible endpoint API for public and private clouds
  • new theme
  • multiple instances for app, msg and ping servers. See the [[LDS/RecommendedDeployment-11.03|recommended deployment]] document for details or the README.multiple-services file in the landscape-server package. Note this is only available when ‘’‘NOT’’’ using the landscape-server-quickstart package.

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.

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 127.0.1.1 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”.

NOTE: ‘’‘BE SURE THIS IS WHAT YOU WANT! IT WILL IRREVOCABLY REMOVE THE STANDALONE DATABASES FROM THE DATABASE SERVER!! THIS SHOULD ONLY BE DONE IF YOU ARE USING THE QUICKSTART PACKAGE AND ARE IN THE ABOVE SCENARIO (PURGE + INSTALL)’’’

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');
DELETE 3
postgres=#

Now to drop the LDS databases:

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

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 ) 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 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.

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 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.

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.

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.

Package availability in the PPA

The PPA 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.

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

Cloud pages don’t work after quickstart upgrade, maybe others too

Due to a bug in the initscripts for some services, sometimes the “stop” action fails to kill the service, leaving it running. In particular, this can happen with the job-handler service. If this happens during the quickstart upgrade, job-handler will be kept running but not in a working state. The workaround is quite simple: just restart it:

sudo /etc/init.d/landscape-job-handler restart

To be on the safe side, and to also determine that all services are properly configured to start at boot, you could also reboot the machine after the installation or upgrade.

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.

Some log files have a numeric suffix

Due to the added support of running more than one copy of some services at the same time, some log files got a numeric suffix to indicate the service instance. These are:

  • message_server-N.log
  • message_server_access-N.log
  • landscape-N.log
  • landscape_access-N.log
  • pingserver-N.log
  • pingtracker-N.log
    Where “N” indicates the instance. The logrotate configuration has been adjusted to handle this.