Tag: connections

Facebook Workplace

A few days ago I had a conversation about the business version of Facebook and the IBM Connections Cloud offering.

In the private sector, Facebook has nearly grown up to a global communication provider because the service is used by almost everyone. The success is not just based on good software but how money is made from the collected information. “Personalized advertising” is only one aspect of the business model.

What you get with Facebook Workplace is a modern software stack with basic social tools. Easy to use and end-user training might take small effort because it’s already well known.

But in general this kind of software is used to store important information, with Facebook as a system ultimately developed for data analysis. There must be a lot of trust given that your data will not used for the daily “big data” business.

Store IBM Connections data on Unix filesystem

The last days I tried to move the IBM Connections datastore (or “shared data” folder) from a single-node Linux system to a Microsoft Windows file server.

The Connections data files are stored in a bunch of folders and sub-folders, managed by the associated applications. Linux filesystems like EXT3 support case-sensitive names. Connections Blogs and other applications create folders with case-sensitive names on this filesystem type to structure the data.

NTFS filesystem which is used on Windows file server does not support case-sensitive file and folder names. As a result it’s not possible to copy Connections data from Linux to Windows filesystem.

This might be annoying in some situations, especially because some of the applications are managing data without braking cross-platform compatibility. The Connections Files application for example stores it’s data in folders with numerical names.

 

Basic troubleshooting with ldapsearch

Ldapsearch is a simple comannd-line tool, helpful for checking LDAP connection parameters and building LDAP search filters.

On many Linux and Mac OS setups it’s installed by default. Fortunately a ldapsearch.exe running on Windows is included in the program directory of IBM Notes Client and Domino Server.

Syntax: ldapsearch -h HOST -p PORT -D BINDUSER -w PASSWORD -b BASEDN (LDAP_SEARCH_FILTER)
# For example: Use a LDAP account for bind to ldap service and search for a single user account with it's CN

ldapsearch -h "ldap.domain.com" -p "389" -D "CN=LDAP Bind,OU=User,DC=DOMAIN" -w "secret" -b "OU=User,DC=DOMAIN" "(cn=Connections ServiceUser)"

You might see some more output from this command. Pay attention to the following messages and probable failure reasons:

‘invalid credentials’

  • Wrong credentials for the LDAP bind user
  • TCP connection to LDAP service is working

’32 No such object’

  • The LDAP Base DN is most propably not available
  • LDAP bind works

‘numResponses: 1’

  • No result for your LDAP search Filter. You can try a search sring like (cn=*) to get an overview of all LDAP entries available.
  • LDAP bind works and Base DN is available

‘numResponses: 2’

  • Search for an single user was successful

IBM DB2 cross-patform migration

If your IBM Connections platform needs to move to a different operating-system (e.g. Windows to Linux) there is an important limitation for the transfer of DB2 data. A simple database backup and restore can not be used when switching the operating system.

For IBM Docs, the Forms Experience Builder (Surveys) or other 3rd-party applications this gets important for the migration from Connections 5.0 to the latest 5.5 release because Surveys and Docs are used in many customer deployments.

The DB2 database transfer for the connections core applications (homepage, files, …) with the DBT tool is working fine and is documented in the official wiki.

To move your Docs and FEB database we need another strategy:

Prepare transfer for DB2 data:

  • Create database on the destination server
    • Use the same SQL scripts the source database was created with
    • Example: If you migrate from Docs 1.0.7 to 2.0 you have to use the SQL scripts from the 1.0.7 packages
  • Update database on destination server to schema version of the source database
  • Grant access (run appGrants.sql for example)

Copy DB2 data:

Use db2move to export/import all data from a database. Execute the commands with the database instance owner (db2admin, db2inst1) on the source and destination server.

  • Run data export on source DB2 server for each database
    • Open command window and change to a temporary folder
    • db2move CONCORD export -u <db2admin_user> -p <db2admin_user_password>
    • <db2admin_user>: User the source database was created with
  • Import data on DB2 destination server
    • Copy the temporary folder with the exported data from the source server to the destination server
    • Open command window on DB2 destination server and change to the temporary folder
    • db2move CONCORD load

Update DB2 database:

  • Update database on the destination server with the SQL scripts from the recent release.
    • Example: If you migrate from Docs 1.0.7 to 2.0 you have to use the SQL scripts from the 2.0 packages to update the database
  • Grant access (run appGrants.sql for example)