Differences between revisions 9 and 14 (spanning 5 versions)
Revision 9 as of 2011-04-06 21:31:19
Size: 5484
Editor: ahasenack
Comment:
Revision 14 as of 2011-04-07 17:52:39
Size: 5591
Editor: ahasenack
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= WORK IN PROGRESS = = LDS installation validation guide =
Line 3: Line 3:
This guide should be followed after an installation of LDS. It's purpose is to verify that all aspects of the installation are working.

Items that need verification:
 * mailing: alerts, invitations
 * computer registration: tests https, message server, ping server, app server
 * access hash-id-database via web
 * run maintenance script one: tests that LDS can reach the AMI database on uec-images.ubuntu.com
 * run update-security-db once: tests that the USN database can be downloaded
 * run hash-id-databases once: it tests the necessary network connections. Note: it will take a while
 * run meta-releases once: it tests the network connection. Note: it also takes a while

TODO: write a single script that makes these tests.
This guide should be followed after an installation of LDS. It's purpose is to verify that all aspects of the installation are working. Please follow all steps below to validate several different aspects of the LDS installation.
Line 20: Line 9:
 * register a computer using the command line provided by the LDS how-to-register page This tests the communication between the client and LDS, both over HTTP and HTTPS.
 * register a computer using the command line provided by the LDS how-to-register page at https://<lds-server>/account/standalone/how-to-register
Line 23: Line 13:
This tests that the mailing configuration is working correctly (for example, postfix is setup in a way that Landscape can use).
Line 28: Line 19:
This verifies that the client can download the hash-id-database for its architecture and version of Ubuntu. This database substantially speeds up the initial synchronization of packages.

Line 42: Line 36:
This tests that the ajax server is running and that the Apache rewrite rules that it needs are correctly setup. It also tests that the clouddeck setup is correct, its daemons are running and that Landscape can talk to it.
Line 45: Line 40:
The above steps test:
 * ajax server
 * clouddeck infrastructure
 * that the maintenance script that was run earlier successfully populated the AMI database. If you only see "Other" in the Ubuntu release dropbox, then it failed.
If you want, you can create an ssh key, start an instance and login.
 1. Start an instance of any size and select a specific Ubuntu release from the drop box. If you only see "other" here, it means the maintenance script wasn't run or failed (see "Cron jobs" above).
Line 59: Line 50:
The tests described above are sufficient to test the deployment of all the Landscape services, as well as all the required network connectivity. You can, however, create some activities that will serve as a demo of LDS for the customer. I suggest to leave package activities to the end, because it takes some time for the package data to get synced and, if such an activity is performed before the synchronization is finished, you will only get an error after 2h. The tests described above are sufficient to test the deployment of all the Landscape services, as well as all the required network connectivity. You can, however, create some activities that will serve as a demo and introduction of LDS for first time users. I suggest to leave package activities to the end, because it takes some time for the package data to get synced and, if such an activity is performed before the synchronization is finished, you will only get an error after 2h.

LDS installation validation guide

This guide should be followed after an installation of LDS. It's purpose is to verify that all aspects of the installation are working. Please follow all steps below to validate several different aspects of the LDS installation.

HTTPS redirection

Access http://<lds-server> and observe that it redirects automatically to the front page using SSL (i.e., HTTPS).

Computer registration

This tests the communication between the client and LDS, both over HTTP and HTTPS.

Mailing

This tests that the mailing configuration is working correctly (for example, postfix is setup in a way that Landscape can use).

  • send out an invitation for another administrator. There should be no significant waiting period (i.e., the admin should get the email quickly as it's not dependent on a cron job)
  • subscribe to the pending computer alert: register a new computer and see if you get the alert in the next 10min
  • subscribe to the offline computer alert: stop landscape-client on an existing computer and wait 10min

hash-id-databases

This verifies that the client can download the hash-id-database for its architecture and version of Ubuntu. This database substantially speeds up the initial synchronization of packages.

Right after a computer registered, keep tailing its package-reporter.log log file. Pretty soon you should see a line similar to this one:

2011-04-06 17:52:02,971 INFO     [MainThread] Downloaded hash=>id database from https://<lds-server>/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_lucid_i386

That means it worked. The important thing is that it downloaded a file for the right distribution and architecture, and from the right server (your brand new LDS installation).

Cron jobs

LDS has several cron jobs that access the network. The purpose of this test is to make sure the current installation allows that.

  • maintenance: run sudo -u landscape /opt/canonical/landscape/scripts/maintenance_wrapper.sh. At the end, you should see it downloading several AMI codes.

  • security db: run sudo -u landscape bash -x /opt/canonical/landscape/scripts/update_security_db.sh. Make sure it succeeds in downloading the security db.

  • hash-id-databases: run sudo -u landscape bash -x /opt/canonical/landscape/scripts/hash_id_databases.sh. It will take several minutes to complete. There can't be any network errors.

  • meta-release: run sudo -u landscape bash -x /opt/canonical/landscape/scripts/meta_releases.sh. Same deal, no network errors. It will also take a while to complete

Ajax server and cloud

This tests that the ajax server is running and that the Apache rewrite rules that it needs are correctly setup. It also tests that the clouddeck setup is correct, its daemons are running and that Landscape can talk to it.

  1. Create a public cloud, using Amazon
  2. List the security groups. You should see at least one called "Default"
  3. Create a security group called "ssh", description "ssh". Click on it, allow ports 22 to everyone.
  4. Start an instance of any size and select a specific Ubuntu release from the drop box. If you only see "other" here, it means the maintenance script wasn't run or failed (see "Cron jobs" above).

    /!\ WARNING: if you used your own AWS credentials for this test, don't forget to remove them before leaving! Or at least invalidate them right afterwards!

Ping server

Access http://<lds-server>/ping. You should see a message like this, still over http (and not https):

ds5:errors19:provide insecure_id;

Additional tests (optional)

The tests described above are sufficient to test the deployment of all the Landscape services, as well as all the required network connectivity. You can, however, create some activities that will serve as a demo and introduction of LDS for first time users. I suggest to leave package activities to the end, because it takes some time for the package data to get synced and, if such an activity is performed before the synchronization is finished, you will only get an error after 2h.

Demo suggestion, considering the machine was just registered:

  • create a stored script and send it to the machine. For example, the script below will display the network interfaces of the machine as well as the current time:

date
ifconfig

Don't wait for it to finish, go ahead with another activity and come back later

  • spawn a machine in the Amazon cloud
  • create a simple custom graph to display the number of processes on the machine:

ps ax | sed '1d' | wc -l

Note: it will take a long time to start seeing an actual line in the graph, like 30min or so.

  • if the package data is synchronized already, you can try a package activity. How to tell? No simple recipe here, I suggest to wait 15min. You could run sudo /usr/share/smart/smart stats on the client and compare that result with what Landscape thinks the machine has.

  • walk the customer through the cloud pages, as they are a bit more complicated than in previous versions of LDS. In particular, explain that clouddeck is acting as a proxy between a cloud client and the actual cloud. You can issue cloud credentials to internal customers, for example, and monitor your cloud usage through Landscape. There are other clouddeck articles on this help site that can help.

LDS/ValidationGuide (last edited 2011-04-07 17:52:39 by ahasenack)