Marcus_F 31000081AD Visits (7842)
In the Connections Homepage Administration UI, users are required to disable each widget or app one at a time. However, by using a combination of wsadmin commands, users are able to disable all enabled widgets or apps from the Homepage.
Once the Homepage administrator role user logs into the Homepage application, and selects the Administration view, they will see that all enabled widgets or apps have now been disabled.
Here's another administration script to cover a common request to add a particular user (e.g. an administrator) to the ACL for every community. We can do this using two wsadmin commands:
In environments with many communities, you'd want to use Comm
from java.util import ArrayList
# Initialize Communities Administration
# Define the new owner to add
# Get all communities
# Loop through the communities and add the new owner to each
In the real world, I'd pass in the email address of the user to add as an argument to the command, but you get the idea. The addM
Also note that because fetchAllComms() returns communities and subcommunities in indeterminate order, you'll need to run the command twice to cover the scenario where we try to update the ACL for a subcommunity before the user has been added to the parent community. The first pass will update all parent communities and any subcommunities processed after their parents, and the second pass will catch any of the subcommunities that were processed before their parents.
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)