Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
Micro Focus Contributor
Micro Focus Contributor
101 views

Collaboration sm-openfire fails OOB.

Jump to solution

Dear Community,

 

My Collaboration integration fails OOB. Please, help.

I installed a horizontaly and verticaly scaled SM 9.63 with Smart Analytics, on an case-insensitive Oracle Express. The webtier, SRC and mobility are all going through one and the same Apache reverse proxy.

Next I installed SMA 2019.08 with one Master and one Worker node, using an external postgreSQL. The SM tenant deploys successfuly and chat is enabled for it.

SMA-SM and the external SM communicate fine, configured for DB authentication and LW-SSO, no SSL. The Apache reverse proxy is configured for chat and SM has collaboration enabled. Everything is by the book.

However, my sm-chat pod fails. It appears to run fine but logging into SM webtier gives "Get chat service configuration failed." The sm-openfire container's log reads

 

[ERROR] LWCrypto encryp or descrypt failed.

 

I suppose this is the reason the sm-chatsvc fails to log in chat server. (sm-chatsvc.log)

I tried to migrate to PKCS12 encoding as instructed in the sm-openfire log. Running in the container

 

keytool -importkeystore -srckeystore /opt/openfire/conf/mykeystore.jks -destkeystore /opt/openfire/conf/mykeystore.jks -deststoretype pkcs12

 

returns

 

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

 

Reinstalling CDF from scratch yealds the same result.

The log files:

sm-chatsvc.log

sm-openfire.log

 

Could I find the default deployment root and keystore passwords to see if it's a simple credentials issue? How can I find if I missconfigured someplace else?

Please, let me know if any other logs or output is helpful. Any suggestions are appreciated.

p.s. Three other topics here ask a similar question. Two of them have no replies and the third involves and external chat server. (It was solved by using an older version of the chat server.)

George Karapetrov

Junior Techology Consultant
https://microfocus.fuze.me/georgi
george.karapetrov@microfocus.com
0 Likes
1 Solution

Accepted Solutions
Micro Focus Contributor
Micro Focus Contributor

Re: Collaboration sm-openfire fails OOB.

Jump to solution

I was using an old certificate for the SM keystore. I should have updated the SM keystore with the fresh SMA "RE_ca.crt" after reinstalling.

In addition, the OOB SM 9.63 did not unload "SD_Portal_201908_SM963.unl" properly, without additional steps.

The unload went through properly (on OOB updated SM 9.63) after my mentor deleted the dbdict entry for PortalNotification. To this end, he renamed the dbdict entry for the SQL table "PortalNotificationsm1" and then remapped all the field entries of PortalNotification to the alias of his new table entry. Then he could delete. Then we could apply the unload through the unload utility, (and list its contents).

Interestingly, the sm-openfire container log error persists:

Nov 25, 2019 14:01:16 CET [ERROR] LWCrypto encryp or descrypt failed.

 yet the chat service functions properly.

To sum up, I had misconfigured the SM side of SMA-SM with an irrelevant certificate. Additionally, a possibly unrelated issue to chat was having to take care of PortalNotification in dbdict before applying the SP unload. Finally, whatever the LWCrypto error is, LWCrypto is a third-party plugin for Openfire, (not produced by Ignite) and a superficial google search does not reveal much about it. Chat functions regardless.

Being a new employee, I don't know if I should open a ticket about the unload. Has anyone else had a similar issue?

George Karapetrov

Junior Techology Consultant
https://microfocus.fuze.me/georgi
george.karapetrov@microfocus.com

View solution in original post

0 Likes
1 Reply
Micro Focus Contributor
Micro Focus Contributor

Re: Collaboration sm-openfire fails OOB.

Jump to solution

I was using an old certificate for the SM keystore. I should have updated the SM keystore with the fresh SMA "RE_ca.crt" after reinstalling.

In addition, the OOB SM 9.63 did not unload "SD_Portal_201908_SM963.unl" properly, without additional steps.

The unload went through properly (on OOB updated SM 9.63) after my mentor deleted the dbdict entry for PortalNotification. To this end, he renamed the dbdict entry for the SQL table "PortalNotificationsm1" and then remapped all the field entries of PortalNotification to the alias of his new table entry. Then he could delete. Then we could apply the unload through the unload utility, (and list its contents).

Interestingly, the sm-openfire container log error persists:

Nov 25, 2019 14:01:16 CET [ERROR] LWCrypto encryp or descrypt failed.

 yet the chat service functions properly.

To sum up, I had misconfigured the SM side of SMA-SM with an irrelevant certificate. Additionally, a possibly unrelated issue to chat was having to take care of PortalNotification in dbdict before applying the SP unload. Finally, whatever the LWCrypto error is, LWCrypto is a third-party plugin for Openfire, (not produced by Ignite) and a superficial google search does not reveal much about it. Chat functions regardless.

Being a new employee, I don't know if I should open a ticket about the unload. Has anyone else had a similar issue?

George Karapetrov

Junior Techology Consultant
https://microfocus.fuze.me/georgi
george.karapetrov@microfocus.com

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.