|Deletions are marked like this.||Additions are marked like this.|
|Line 9:||Line 9:|
|This tests the communication between the client and LDS, both over HTTP and HTTPS.|
|Line 12:||Line 13:|
|This tests that the mailing configuration is working correctly (for example, postfix is setup in a way that Landscape can use).|
|Line 17:||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 31:||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 34:||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).|
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.
Access http://<lds-server> and observe that it redirects automatically to the front page using SSL (i.e., HTTPS).
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
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
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).
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.
- Create a public cloud, using Amazon
- List the security groups. You should see at least one called "Default"
- Create a security group called "ssh", description "ssh". Click on it, allow ports 22 to everyone.
- 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!
Access http://<lds-server>/ping. You should see a message like this, still over http (and not https):
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:
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.