|Deletions are marked like this.||Additions are marked like this.|
|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.
||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 10:||Line 9:|
|* register a computer using the command line provided by the LDS how-to-register page||* register a computer using the command line provided by the LDS how-to-register page at https://<lds-server>/account/standalone/how-to-register|
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).
register a computer using the command line provided by the LDS how-to-register page at https://<lds-server>/account/standalone/how-to-register
- 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
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
- 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.
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.
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.