A multi server Landscape Dedicated Server charm.
- app-servers ›
The Landscape systems management tool helps you monitor, manage and update your
entire Ubuntu infrastructure from a single interface. Part of Canonical’s
Ubuntu Advantage support service, Landscape brings you intuitive systems
management tools combined with world-class support.
This charm will deploy the dedicated version of Landscape (LDS), and needs to be
connected to other charms to be fully functional. Example deployments are given
For more information about Landscape, go to http://www.ubuntu.com/management
The typical deployment of Landscape happens using juju-deployer. This charm is
not useful without a deployed bundle of services. Please read below for how to
deploy all services necessary for a functioning install of LDS.
NOTE: This section will be superseded by a juju "bundle", when that is ready.
You can use juju-deployer to greatly simplify the deployment of Landscape to a
real cloud. Inside the charm, there is a "config" directory that contains a
deployer configuration file that encapsulates all the charms and their
configuration options into what we call "deployer targets".
juju-deployer is packaged and available in the juju PPA. If you don't have that
PPA, you can add it like this:
$ sudo add-apt-repository ppa:juju/stable $ sudo apt-get update
Then install deployer:
$ sudo apt-get install juju-deployer
Grab the landscape charm:
$ bzr branch lp:~landscape-charmers/charms/precise/landscape-server/trunk $ cd trunk/config
Prepare the repository and license files (See "Configuration" section for more
$ vim license-file # Put the license text in this file $ vim repo-file # Put the URL part of an APT sources.list line here
Change the passwords used in the landscape-deployments.yaml file in the
"monitoring_password" and "landscape-password" keys to new values:
$ vim landscape-deployments.yaml
Now we are ready to deploy (the -w 180, -v, -d, -W flags are optional, but
nice). The "landscape" deployer target is the one you should start with. It
uses 6 machines plus the juju bootstrap node:
$ juju-deployer -vdW -w 180 -c landscape-deployments.yaml landscape
NOTE: After juju-deployer finishes, the deployment is not entirely ready yet.
Hooks are still running, and it can be a few minutes until everything is ready.
You can point your browser to the apache2/0 unit and keep reloading until you
see the form to create the first Landscape administrator, and/or follow the
output of juju debug-log until it shows that all hooks are done.
To view what other deployment targets are available, use the list option:
$ juju-deployer -c landscape-deployments.yaml -l
Landscape is a commercial product, as such it needs configuration of a license
and password protected repository before deployment. Please login to your
"hosted account" (on landscape.canonical.com) to gather these details after
purchasing seats for LDS. All information is found by following a link on the
left side of the page called "access the Landscape Dedicated Server archive"
config/landscape-deployments.yaml supports reading a
license-file in the
config directory. Take the license file you downloaded, put it in the file
config/license-file, and juju-deployer should read it in and deploy as
You can also set this as a juju configuration option after deployment
on each deployed landscape-service like:
$ juju set <landscape-service> "license-file=$(cat license-file)"
Put just the URL part of the "deb ..." line into a file called
config/repo-file and juju-deployer should read it in and depoy as usual.
At this time, this setting is not changeable after Landscape has been
$ cat config/repo-file https://username:email@example.com/ $
The included deployment targets will ask Apache to generate a self signed
certificate. While useful for testing, this must not be used for production
For production deployments, you should include the "real" SSL certificate key
pair in the apache charm configuration.
The config/landscape-deployments.yaml deployer configuration file has two
deployment targets available:
Targets that start with an underscore should be ignored as they are used
internally only. Your choice of target should be made taking into consideration
the scaling options available for each one and existing resources in your
The "landscape" target is a good compromise between scalability and resource
usage. This deployment will give you 6 units (plus the bootstrap node):
* single database server, acting as master
* one landscape message server unit, responsible for managing the computers
you have registered with landscape
* one other landscape unit which hosts the other less resource-intensive
* apache, haproxy and rabbitmq-server each in its own unit
There are three common scaling out options for this deployment:
* if you need Landscape to handle more computers, add another landscape-msg
* if you need to allow more concurrent access for administrators, add another
* add another database unit if you want database replication. The replication
configuration happens automatically.
The "landscape-dense" target deploys everything on the bootstrap node in the
* apache2, the frontend, is deployed directly on the bootstrap node,
using the co-location feature
* the other services are deployed into containers
On non-MAAS providers, containers do not get routable IP addresses. But the
only service that needs to be reachable from the "outside" is the frontend, so
it doesn't matter that, for example, postgresql or rabbitmq-server or any of
the other services have private internal-only addresses. Apache2 can still
see them and proxy connections as needed.
You will need a big enough bootstrap machine for this deployment. Comfortable
* 20Gb disk for deployment and OS (about half used for /var/lib)
* 10Gb of RAM
The "landscape-dense-maas" target is just like the "landscape-dense" one,
but everything is deployed using containers. Even the frontend.
This works when MAAS is the provider because in this case containers get
routable IP addresses, so the frontend can be inside a container too.
The hardware constraints are the same as for the "landscape-dense" target.
You can customize the Landscape deployment quite a lot. Via the "services"
charm config option you can select exactly which landscape services (or
processes) you want running where, and also how many copies per unit. Look at
the config.yaml file for details on how to use this option.
The Landscape charm is fairly well unit tested and new code changes
should be submitted with unit tests. You can run them like this:
$ sudo apt-get install python-twisted-core $ make test
This charm makes use of juju-deployer and the charm-tools package to enable
end-to-end integration testing. This is how you proceed with running
# Make sure your JUJU_ENV is *not* bootstraped, and: $ sudo apt-get install python-pyscopg2 python-mocker python-psutil $ JUJU_ENV=<env> make integration-test
- (string) Email of the account administrator. To have any effect, needs to specified in conjunction with admin-name and admin-password. Has no effect if changed after a deployment.
- (string) Name of the account administrator. If this, admin-email and admin-password are specified, then the standalone account will be created as part of the deployment, and this person will be its administrator. If not specified, Landscape will prompt for these details when it is first accessed with a web browser. Has no effect if changed after a deployment.
- (string) Password of the account administrator. To have any effect, needs to be specified in conjunction with admin-name and admin-email. Has no effect if changed after a deployment.
- (string) Key ID to import to the apt keyring to support use with arbitary source configuration from outside of Launchpad archives or PPA's.
- (string) The password to use for the landscape DB user. If you change this post-deployment via juju set, you will have to change the password in the DB manually as the charm will not do it for you yet.
- (string) License file for LDS.
- (boolean) Put this landscape service unit into a maintenance mode. Stop all services and prevent any attempts to start them. Cron jobs will also not run. Upgrade schema attempts will still be allowed to process.
- (string) Many landscape services can have multiple instances started up. By altering this setting, you can increase the launch count. A numeric value will tell all capable landscape services on this juju unit to spawn that number of instances. Leave at the default of "AUTO", to let the charm determine the optimum number of services given the discovered properties of the box (RAM, Disk Space, CPU). You can also supply a syntax of: "<service-name>:<number> <service-name>:<number>" as a value, to control the launch of individual services. Services that cannot "scale" in this way will politely ignore these settings.
- (string) Landscape services listed as space-separated entries. Valid services are: appserver, msgserver, pingserver, combo-loader, async-frontend, apiserver, package-upload, jobhandler, package-search, juju-sync, cron and static.
- appserver msgserver pingserver combo-loader async-frontend apiserver package-upload jobhandler package-search juju-sync cron static
- (string) APT repository to use for installing Landscape.
- (boolean) When daemons attempt to start, they will first try to update the schema (instead of just validating that it is correct). This should only typically be enabled as part of a landscape maintenance cycle.