So my entire infrastructure is on RHEL 6.7 (except MCU, which is 6.5 because MCU is picky). I personally hate typing, mainly because I really stink at it. In order to make my life easier, I've created start and stop scripts for all my servers. This is especially crucial for servers like the Video Manager, which require startup in a specific order. I chose to do this instead of creating services that auto start, just because I'm a control freak who likes to manually control everything. It's probably helpful to understand that my SSC, Community and DB2 servers all reside on a single VM (not recommended for production of course).
#1: Without further ado, here's my Community/SSC/DB2 startup script
This script, like all my scripts, resides in the "/root" directory with 700 permissions. This ensures it can only be run by root.
So the first section, titled "Kill any leftover pids, is because often when one of our servers shuts down dirty, it leaves pid files laying around. If you don't kill these off, your server will startup in a bad state, if at all. Obviously, if you have anything other than a Sametime server installed, you should make sure the other programs don't also leave pids in the "/opt" directory, lest you discover new and interesting ways to break them when you run this script.
#2: Stopping is slightly different
First, you need to type "quit" in the terminal window where Domino is running. Then you can run the following script to stop. Note that you have to pass in username and password to stop the server.
Again, straightforward. Note the stopping order is the inverse of starting.
#3: Advanced script for other servers
The other servers are not quite so interesting, here's the Advanced script (I have a cluster, and the WAS proxy resides on this node, so there's an extra line to start the proxy).
Stopping follows the same template as the Community script.
#4: Starting SolidDB to ensure Vmgr startup success
You can use the above scripts as general guides for any server you wish, with the exception of the Video Manager (Vmgr) and the MCU. The MCU is (or should be) started automatically. The Vmgr is a stand alone server (not federated to the SSC lke all the other children) so you have no node agent to start, but you do need to make sure SolidDB is started first - it's critical to successful Vmgr startup.
#5: Shutting down Vmgr
Shutting down the Vmgr is unique as well; after running the script you'll have to enter SolidDB credentials (default is admin:admin)
CallieSummers 310000FFS1 Visits (7594)
There is a new release of the Ephox Editors that supports the Microsoft Edge browser and includes a number of cumulative fixes. Read about it and get it here.
Find more info on Ephox Editors in the Knowledge Center: Opti
Brian Erle (IBM) 1200008FU8 Visits (7942)
"How do I go about changing the database user ID and/or password used to connect IMC with my database?"
This is a task an IMC Administrator will face periodically, and it is best to know how to update IMC quickly BEFORE the database credentials change so your system can be prepared for this change. Full details on how to affect this change may be found in Technote 1686681.
Please Note: Do not attempt to change the Userid / Password directly with the Gatekeeper as it will not work.
Chad Scott 110000E1UB Visits (7537)
Here's one I ran into when installing the Connections 5.5 CR1 Cognos Wizard updates on my Transformer node. Installation Manager calls various Cognos scripts, including the cogn
REM Make sure there is jre for use
The problem occurs when the SET /p statement is invoked. This is a user prompt for a path to a valid JRE on the system. However, since this script is running under the covers for Installation Manager, the user will not see a prompt, and the install will appear to hang forever. You can work around this by setting JAVA_HOME in cogn
Prior to installing CR1 for Connections 5.5, I thought it would be a good idea to clean up the old installation files in C:\IBM\Connections that were left over from 5.5. In addition to deleting the .log files, I also discarded the .py script files. Big mistake! At least the install.log file clearly showed the problem:
Traceback (most recent call last):
The lesson here is that it's fine to delete old .log files, but don't toss out the other files with them.
Chad Scott 110000E1UB Visits (10091)
Check out Part 3 of my Connections 5.5 Small Deployment series of guides, which takes you through the process of applying CR1. It's a mostly straightforward process, but I did run into a couple of gotchas with the Cognos components.
Dwight Harper 120000A87B Visits (5649)
I am a Knowledge Manager for Sametime and IBM Connections Chat Cloud.
Prior to this role, I was a Sametime Support Engineer. As part of my duties, I facilitate weekly Sametime brown bag learning sessions with our internal Support and Services staff. This is a place where subject matter experts present a topic and attendees ask questions and share experiences in an informal setting.
Some of these tips really hit home with the engineers, so I thought you might be interested in them as well.
These three videos are excerpts from the session, each covering an area of LDAP configuration in Sametime.
Video #1 - When to manually tune Wimconfig.xml in Sametime LDAP
Video #2 - Minimizing risk of failure in Sametime LDAP
Video #3 - Secrets behind the usage of the Directory Assistance by Sametime LDAP
I hope you will enjoy these tips from a seasoned support veteran!
Brian Erle (IBM) 1200008FU8 Visits (6986)
The use of certificates in IBM Mobile Connect (IMC) is prevalent. From securing incoming device requests, to securing connections to databases, authentication servers and application servers certificates are a part of the everyday operation of an IBM Mobile Connect deployment. When everything is working perfectly no one really worries about those certificates securing sessions until they expire and everything comes to a grinding halt. This can happen literally in the blink of an eye. What was a perfectly valid incoming device request a millisecond ago, is now an expired request. In the wg.log from IMC you will see a message which will look like this:
[ERROR] SSLPort: failed to attach secure connection, fd=21: [10.10.10.10:33622] GSK_ERROR_BAD_DATE (rc=401,ec=401)
Using the IBM Key Manager an administrator can examine the certificates used to secure incoming devices. By examining the certificate in the Personal Certificates view and then using the VIEW action you can check for the expiration date for the certificate and then execute on a plan to ensure that a new certificate to replace an expiring one is in place and ready to go prior to the expiration date of the present certificate. The ACTIVE certificate is the one with the asterisk '*' symbol next to it. When it comes time to use the new certificate select the certificate and View it, then choose the option near the bottom of that dialogue which allows you to set it to the Default certificate. In order for IMC to begin using this certificate a Stop and Start of the Connection Manager is required.
324:745822528 (Apr 18 2016
Please Note - the LOG and DEBUG logging levels are required to be active to see these messages. IBM IMC support and development recommend that only ERROR and WARNING log levels are used during normal production operation for optimal performance.
The above message indicates that a secure request was received, and accepted, and there was no error, and the last message will also indicate which HTTP Service (if there are multiple services configured) handled the request.