Technote: “Freemarker Template files are overwritten during IBM Connections CR2 install”


This happened to me, I was only saved by having a local back-up on my machine … don’t let it hit you!

Technote Link – swg21996243

Hving a good back-up before ANY upgrade, change etc. is important. If nothing else, do a backup config with WebSphere – that will capture all of the important files for you as well!

 

 

 

 

Advertisements

IBM WebSphere / Connections – Performance, Security and the SESN0008E Error


Just found a new issue today that has been vexing me for quite some time, I only found it because of the error [SESN0008E] and the fact that I had to add a whole new WebSphere Nodes to an existing environment so that these errors finally happend with a frequency that I finally noticed it:

logServletError SRVE0293E: [Servlet Error]-[atom-basic]: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:defaultWIMFileBasedRealm/CN=Joe Shmoe,OU=MYOU,dc=corp,dc=company,dc=com

We ran function testing on the new Node and performance was horrendous … I mean really horrendous. Performance has been bad overall before that, but at least tings worked. I investigated a few tech notes, there was some mentioning about the LTPA timeout being too short in combination with several other settings. This is an upgrade, same settings as other systems, should not be an issue … so I looked at other sites/pages here, here and here.

All of the tech notes mentioned [Security Integration] being at the heart of it. I checked all servers and noticed – none of the server that the Connections installer created had this settings set, all servers that I created manually had it. I looked into this a bit more and found out that the [Session Management] – [Security integration] is now a default setting for WebSphere and if you create a server manually it is automatically set. I ran a few third party products in separate servers that were all manually created … they probably brought the overall performance down.

So, I went through all servers that I had created, unset the settings (pic below) and then synced and restarted everything and …. voila, speed restored.

sessionManagement

Connections 5.5 – Install Problem for WebSphere Cluster Settings with UNC Shares


I just installed a new Connections V5.5 environment for a new client and came across this issue that I had encountered once before in previous versions when installing the IBM File viewer (look at my presentation from last year at MWLug 2015) .

Scenareo:

  • Connections 5.5,
  • Clustered Windows WebSphere servers (2 nodes on separate Windows server)
  • Windows File Share for shared file services (accessed using a UNC link i.e.: \\[fqhn of server]\[share name])

The Installer will go through and work without a problem, all apps are installed and the clusters in WebSphere created. When you run the WebSphere servers/JVMs for the first time you might notice a new folder created on the same drive as your WebSphere install, the name follows the above UNC naming for the shared file services location. In my case the folder created was [D:\FILESERVER\CnxData\messagestores\xxx).

Messagestores are the way that messaging engines running on WebSphere clustered servers communicate with each other by reading/writing log files (there is much more to it, but let’s keep this lite here …). Both Windows server will create the same folders and you will probably not see a whole lot of errors in the systemout.log files of the WebSphere servers because … those servers can access the files they expect, that they are not getting any inputs from other cluster members is not going to raise any errors inside of WebSphere.

In V5.0 what happens is that the installer creates a WebSphere variable and uses that variable in the cluster settings and then the system works and the UNC drive is read correctly. The V5.5 installer does not do this, it writes the location directly into the sib-engines.xml file of the cluster created and then things fall apart ….

 

What to do:

Basically you have to manually do what the installer should have done:

Create a WebSphere variable

  • I created the same one as V5.0 would have [MESSAGE_STORE_PATH] and gave it the value of the UNC folder location in WINDOWS format (using “\” slashes): i.e. [\\servername\share\messagestores]

Update the sib-engines.xml

  • Search for the sib-engine.cml files  on the Dmgr profile under: ..\WebSphere\AppServer\profiles\Dmgr01\config\cells\[cell name]\clusters\[Cluster Name]
  • Edit the last line in the file for each cluster to look something like this:
<fileStore xmi:id="SIBFilestore_1456105865384" uuid="5976E93BC88E6CB1" logSize="100" minPermanentStoreSize="200" maxPermanentStoreSize="500" minTemporaryStoreSize="200" maxTemporaryStoreSize="500" logDirectory="${MESSAGE_STORE_PATH}/UtilCluster/log" permanentStoreDirectory="${MESSAGE_STORE_PATH}/UtilCluster/store" temporaryStoreDirectory="${MESSAGE_STORE_PATH}/UtilCluster/store"/>

Note the use of “/” in this entry, do it that way!

Do the WAS Thing:

  • You need to then sync the nodes and restart all servers/clusters and then WebSphere will create the folders and subfolders is needs and all will be well ….

 

After a restart you can delete the incorrectly created folders, they do not contain any data you need, the data written into there is transactions and will be re-created when the servers restart.

IBM File Viewer 1.0.7 Installation – Getting Past The Conversion Server Install Woes


I will keep this short and sweet – to use the free IBM File Viewer with IBM Connections 5.0 with CCM you need to have Connections at CR2 and install IBM File Viewer 1.0.7. So far so good … until you run into all the issues that everybody has been having with the Installation of the product, the Conversion Server install fails … allot, often, and with annoying frequency.

There are two main problems with the Doc Conversion installer:

Problem 1: Doc Conversion Install Fails – Unexplained

The error most people see is this one in the installation log:

2015-06-22 19:53:58,236 INFO Setting Websphere variables…
2015-06-22 19:53:58,236 INFO Exception: cannot concatenate ‘str’ and ‘NoneType’ objects
2015-06-22 19:53:58,236 INFO –>IM:ERROR:Traceback (most recent call last):
File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\common\commands\command.py”, line 197, in exec_commands
_do(cmd, cmd_instance)
File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\common\commands\command.py”, line 108, in _do
res = cmd_instance.do()
File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\conversion\set_websphere_variable.py”, line 30, in do
succ = self.__set_variable(“CONVERSION_INSTALL_ROOT”, CFG.install_root_on_node)
File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\conversion\set_websphere_variable.py”, line 43, in __set_variable
log.info(“Setting ” + name + ” as:” + value)
TypeError: cannot concatenate ‘str’ and ‘NoneType’ objects

The funny thing is .. I got it to install a few times and then with other clients it woudl fail and I was not able to determine why … until I took a closer look at the python script that it references and the actual error it gives you:

File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\common\commands\command.py”, line 108, in _do
res = cmd_instance.do()
File “C:\Install\IBM_File_Viewer-1.0.7.20150213-2234\DocsConversion\installer\conversion\set_websphere_variable.py”, line 30, in do
succ = self.__set_variable(“CONVERSION_INSTALL_ROOT”, CFG.install_root_on_node)

If you look at the python script, it is basically called to set a few WebSphere variables:

def do(self):
log.info(“Setting Websphere variables…”)
succ = self.__set_variable(“CONVERSION_INSTALL_ROOT”, CFG.install_root_on_node)
if not succ:
return False
succ = self.__set_variable(“DOCS_SHARE”, CFG.getSharedDataRoot())
if not succ:
return False
succ = self.__set_variable(‘VIEWER_SHARE’,CFG.getViewerSharedDataRoot())
if not succ:
return False
log.info(“Websphere variables set completed”)
return True

This is when I noticed  – the CONVERSION_INSTALL_ROOT variable calls for the  string [CFG.install_root_on_node] -> the point is – ON NODE. I did some more digging and … the variable for the install root is not taken from the main [cfg.properties] file but rather looked up in the [cfg.node.properties] file.

This explained allot – I would not always create that file before the install on the first Websphere noded even if the install documentation called for it since I did not think I needed it. By default that file does not exist, the installation package only contains a file called [cfg.node.properties.sample]. The documentation / WIKI tells you to create the file and copy the whole content from the [cfg.properties] into it but does not tell you why you might need it. If you don’t plan to install a secondary node or will only install it on another physical machine you might never create this file and the installer will fail forever because there is no good error handling AND no explanation as to why the [cfg.node.properties] file is important. Frankly, the way the installer works why you even need the [cfg.node.properties] is beyond me, but I assume there are some IBM Docs install variables that are necessary and IBM wants to keep the number of code changes necessary to a minimum.

Problem 2: Passwords saved to Install.log in the clear

This was something that my buddy Christoph Stoettner had already noticed and talked to me about a while back – not sure if he blogged on it but in any case, here is a shout out to him as he noticed it first.

The installer will stop and restart the IBM HTTP server for you, but for that it needs an OS admin account and asks you for it in the command line. It then promptly logs the entry in clear text in the installation log … a really great example of excellent security that makes me shudder and want to have a very long talk with the developers of the product ….. This is almost criminally negligent.

There is a great way around this,  though the IBM File Vieweer documentation fails to tell you about it: create a JOBS TARGET for all servers involved in the installation in WebSphere. Though technically you only need the HTTP servers registered, I usually crate the targets for all servers. Here is the documentation on how to do it from the IBM Docs documentation. Alternatively you can also just not have the installer restart the IHS, set the variable [restart_webservers=] to [False] and the system should not ask you for the username and password.

If you have already installed the IBM File Viewer – go back to the installation logs and check for the line:

WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: “[[[\’ihs.servername.com\’, \’adminaccountname\’, \’adminaccountpassword\’, \’windows\’, 0]]]”

Note: I replaced the server name, account name and password in the above example so just look for the logging code [WASX7303I]

Hope this helps, I know I was pulling may hair out and even had a PMR opened IBM that did not help me solve the issue originally as we never found out what really caused the problem – the poor IBM tech was pulling his hair out along with me and the IBM Docs support guy also was not able to help as they do not really work with the IBM File Viewer and do not know the product and what the installation procedure looks like.