Detangling wires behind the stereo
I am still detangling wires, but not the ones behind the stereo. These are the tangled 'wires' that make up the install , configuration and deployment of the Communications Suite Software.
The deployment is not that hard but it is not that easy either. The tough part is to tune into the fact that the tools that generate the initial configuration will naturally default to giving the local hostname as the answer to any question that involves the use of a hostname. This is not so bad, its just that when you deviate a little from the defaults, you still need to have some guardrails to help you stay on track.
So, where are the guiderails / guardrails? Well they are there if you step back and slow down just a little. You can make them up by disecting the deployment into its essential services. A look at the software used for the Communications Suite shows a stack with various pieces of software and there are services are layered on top of each other. For instance, the Directory Server sits at the bottom, followed by the user provisioning system, which are then followed by the other individual server software that use the information stored in the directory. To setup some guide rails, assign some mnemonics that refer to those services:
ug-ldap, address-book, axs-mgr, be-msg, be-calndr, be-iim, fe-msg, mta-out, mta-in, fe-mmp
... for starters.
With that in place, the next part is to narrow in on what components should be activated so as to deliver that service from an isolated standpoint. This involves making a service specific list of what needs to be in place. Just a one liner that tells what action should be done. Actions include 'install component X, configure component Z, execute program Y. This process is repeated and the service specific lists are then joined into a comprehensive list. As each list is joined to the comprehensive list, the service name is prepended before the name of task entry. This results in a list that distinguishes the install of component X for the ug-ldap service vs. a list entry that refers to the install of component X the be-calndr service. The comprehensive list resembles the following:
All nodes execute 0105.general.common.create_runtime_accounts.sh All nodes execute 0106.general.common.apply_OS_patches.sh All nodes install shared_components All nodes execute 0108.general.common.apply_OS_patches.sh Directory Server Execute 0202.ug-ldap.common.patch_newly_Installed_products.sh Directory Server Configure directory_svr component Access Manager Server execute 0205.axs-mgr.common.ensure_ldap_service_is_listening.sh Access Manager Server execute 0356.axs-mgr.common.print_product_summary.sh Backend Message Store install messaging_svr component Frontend Message Server install integrated_web_client component Frontend Message Server Configure messaging_svr component Frontend Calendar Server Configure calendar_svr component Outbound MTA configure messaging_svr component Inbound MTA install messaging_svr component
So there you have it. That is the first principle behind the design of the
EMRA Toolkit - detangling those wires.
Posted at 04:07PM Jun 23, 2009 by Anthony Waldron in The EMRA Toolkit | Comments[0]