By joesciallo on Apr 30, 2008
Running the Delegated Administrator configuration script,
config-commda, takes a longggg time to complete on a not-so-swift host.
The subtitle of Installing Comms Suite, Day 2, ought to read "I'm my own worst enemy." After finally getting past the point of installing Application Server, Directory Server, Access Manager, and Web Server, as detailed here, I finally got on to the long-awaited installation of Comms products themselves, and then being able to run the
comm_dssetup.pl script, which would apply the necessary schema for Comms to the Directory Server. Ah, at last, smooth sailing ahead.
Except that the script would not recognize my Access Manager installation. When choosing my Schema type as Schema 2, (which the Single Host Deployment Example uses), the script responded:
Please enter the Schema Type (1, 1.5, 2) : 2 Access Manager has not been configured for this new user/group suffix You can opt to continue, but you will not be able to use features that depend on Access ManagerHmmm, odd I thought. No problem, I'll just uninstall Access Manager and reinstall, just to be sure. One uninstall/reinstall, same result. Twice, same result. Okay, third times the charm. Same error message.
Then I actually stopped to read a little burp of an error in my term window:
has_naming_context_ds6 get-suffix-prop result: execv(/opt/bits/jre1.5.0_15/java/bin/java): No such file or directoryA little poking around, and sure enough, I was setting a bogus
comm_dssetup.plwas complaining! Naturally, when I fixed this I was on my merry way.
Next step: Running all those Comms configurators. Where's the easy button when you need it?
Right now, for the second time, I'm re-uninstalling the Identity Suite components needed for a Comms deployment. That would be Directory Server, Access Manager, and Web Server. Why you ask? Because I can't follow my own instructions. (Big grin.)
Lesson One: Don't cut corners.
When I started this exercise, the first step was to install Application Server 9.1 Update 1. That requires Java 1.5. My system, running Solaris OS 9, only had 1.4. At first I thought I could just download and install the JRE; a smaller download than the entire JDK. Okay, I cut a corner. I installed the JRE (and had to figure out where my PATH was still picking up the older JRE and preventing me from launching the Application Server installer) and ran the Application Server installer. Well, one of the options was the location of the Java 2 SDK 5.0 or higher. Urg. I did need the entire JDK. So I had to exit the Application Server 9.1 Update 1 install, hunt down the new JDK, then download it, then install it. More lost time.
Lesson Two: Read the documentation. Closely.
In my case, I mistakely choose to install all the Identity Suite components (as well as all the multi-national languages, which aren't necessary for my POC, and take up lots more time to install as well). This had the unfortunate effect of installing a second copy of Application Server, version 8.2, which I \*think\* overlayed my initial installation of Application Server 9.1 Update 1, needed for Convergence (Kendo). If I had followed the doc, I would have skipped installing this second conflicting version. (And as I'm writing, the IS uninstall just finished. It is not a quick process on a slow machine, trust me.)
BTW, finding out how to uninstall the Identity Suite components wasn't an easy Google. I finally found out on a Sun Forum how to do it:
Much of the time during this exercise, I find myself asking: Is this typical of the customer experience? If so, once again, I'm feeling your pain.
I'm on to reinstalling the Identity Suite components at this point. More later.
BTW, some things I've had to learn along the way:
When I first started this exercise, I wanted to blog about how we in Comms need to, and are trying to, lower the barrier to installing Comms Suite. That is, an admission that for many customers, installing just a proof-of-concept Comms deployment does have some aspects of rocket science to it.
But for now, I'm feeling the pain, as they say, much like this poor fellow:
Stay tuned for more details of my experience. In future blog entries I will also be describing the positive strides we are taking towards making installing Comms an easier and better proposition.
Shane Hjorth has a new article on the Communications Suite 6 Wiki titled "Performance tuning Realtime BlockLists (RBL) Lookups." This article comes about as a respone to a recent number of cases/forum questions regarding the performance of blacklist lookups. Note that with Messaging Server 6.3, there were a few changes to help improve the performance (remove a bottleneck). Read the article here.
And remember: as this is a wiki, you can log in with your SOA account and contribute!
A few questions about the Communications Suite 6 release have come up this week, thought I'd pass them along.
Q. Can I simulaneously deploy the new Web client, Communication Center, alongside the existing web client, Communications Express?
A. The plan is that the new Communication Center and the existing Communications Express will be able to co-exist. We understand that some customers will need to continue using Communications Express for various reasons before completely switching over to Communication Center. We have conducted in-house testing of this co-existence scenario. Unofficially, we have had two setups: one in which CE is deployed in Web Server 7.0 and CC in Application Server 9.1 U1, as their respective web containers; and a second in which both are deployed in single Application Server 9.1 U1 web container. I repeat, these are unofficial, not fully tested/qa'd at this point.
Q. I've noticed that both the Identity Suite and the Communications Installer install the comm_dssetup.pl script, for modifying the LDAP directory schema. Which should I be using?
A. You want to use the comm_dssetup.pl script installed by the Communications Installer. The version provided by Identity Suite is out of date. However, if you install Identity Suite before the Communications Suite components, there is an issue. You will need to run the commpkg upgrade command to force an upgrade of the existing comm_dssetup.pl installed by Identity Suite, to the newer version bundled with the Communications Installer and Communications Suite 6 components. (If you just run commpkg install, and it already detects comm_dssetup, it will not install the newer version.) See the Note at the bottom of this page for more information.
Q. I am working on installing Communications Express in the beta program with IM Server integration. The section "Configure IM Components to Enable Communication with the Instant Messaging Server" mentions the following:
Provide the Httpbind JID and password. The Httpbind JID should be a meaningful string.What relationship does the JID have with a DNS name/hostname? Also, is the password mentioned here relative to a JCS component or something arbitrary for this portion of the configuration?
A. As far as the JIDs are concerned, they can be any arbitrary string. We have been embedding the host and domain in the string by convention but it doesn't have to be that way. Because the server can be distributed from the gateway the only stipulation is that the entries in the server's iim.conf file and in the gateway config files should match. That goes for passwords too. So when you view the httpbind jid in the iim.conf and the httpbind.conf files they should match. The JID is our way of providing component authentication with the server. Naming all JIDs the same (such as hostname) will probably cause problems especially when the server is talking to multiple components which may be running on the same host. Hence we use "httpbind" and "avatar" in our examples to distinguish the two.
Communications Installer (CI) only installs Communication Suite components: Calendar Server, Communication Center, Delegated Administrator, Instant Messaging, Messaging Server (32- and 64-bit), Communications Express, and Sun Cluster Agents for Messaging Server, Calendar Server, and Instant Messaging. The CI also installs necessary shared components and required patches for Solaris OS. You will need to use the Java ES distribution, and the Java ES installer, to install dependant components, such as Access Manager, Application Server, and Directory Server.
No, it is still a single host installer. However, if you are interested in simplifying multi-host deployments, see Enterprise Messaging Reference Architecture Toolkit.
No. The CI does not contain a GUI, only a CLI and silent install.
commpkg. See commpkg Usage for more information.
Yes, through the use of the
--altroot switch. Again, see commpkg Usage for more information.
Today we are making available the Communications Suite 6 Beta Refresh, which includes the new Ajax-based client, Communication Center.
To those of you participating in the Communications Suite 6 beta program, here are the doc links of interest that pertain to the new client:
When it comes to searching for information, let's face it: you want to find it quickly and have pertinent search results to choose from.
With that in mind, I'd like to recommend the built-in search facility to wikis.sun.com for finding information that we are building on the CommSuite wiki.
Confluence's search facility performs a full-text search of all content on the CommSuite including pages, comments, and attachments.
To search the CommSuite wiki, simply type what you are looking for in the "Searching Sun Java Communications Suite" bar, located on the CommSuite landing page.
Notice what happens when you type: the search already begins displaying results for you even before you press enter. For example, here I am searching for "install":
If you don't find a search result here that you like, click the Go button, and you'll get the full set of results, and other search options.
From this page, you can:
Have a look:
If you get a Sun Online Account, you can also contribute!
Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.