Lotus Nut

First of all, there is an 8.0.1 DWA hotfix available. If you or your customers are experiencing some issues with DWA 8.0.1, you will want to open a PMR with IBM Support in order to see if this hotfix addresses your problems. One of the major problems we found is the caching of attachments with the same name in IE. If you receive two attachments with the same name from different senders, the first one you open is cached until you logout. But there are some other fixes in the hotfix.

Secondly, there is a HF6 available for Quickr 8.1.

Adding members to places in Quickr 8.1 is a lot simpler (and cooler) than in 8.0. Just go to the members dialog and choose to add a member. You get a nice interface with the Web 2.0 typeahead we're all used to.

 

 While following the install guide for Quickr 8.1 HF2 (which is out now, by the way - along with a separate Connectors HF2), the upgrade did not go so hot. After starting HTTP and running the 3 qptool commands, I was only seeing a white screen in the browser - nothing would render in the window.

I did notice when I started HTTP that I received a "- File modified at operating-system level while cached, please retry open." error. So at this point I decided that something definitely wasn't right. I decided to just quit the server and redo the HF2 "installation" (which "is straightforward, basically copying over existing files or adding new directories and files.". This took care of the problem.

The moral of the story: you may wish to completely end the Domino server instead of just HTTP.

One of the Domino Server security settings that I rarely see implemented is the option to "Enforce Server Access Settings". In the link, you can see that Ted describes the feature nicely.

With Quickr, you have the ability to grant access to places for people not listed in your directory. However, I have found that there is a "gotcha" when using this Domino security option if you also have the setting to only allow "Users listed in all trusted directories" checked in the Security tab of the Server document. Since the internal "place users" are not in your Domino Directory, they will not be able to log in.

But there is a way around this. With specific place users, they are created in the ACL as me@domain.com/placename/QP/DominoDomain. So this means that along with the "Users listed in all trusted directories" that you should be able to add */QP/DominoDomain to also be allowed to access the server.

Oh, and you'll also have to make sure that LocalDomainServers (or some other server group) has access to the server as well.

Looks like these two products are now in the wild! Documentation for both products is forthcoming, so check here for Sametime Advanced (as a new topic in the menu) and here for Quickr 8.1.

I've already upgraded a Quickr server. Daniele Vistalli has some quick, but good, notes on upgrading from Quickr 8.0.0.x.

And I'm currently setting up a VMWare machine to use for Sametime Advanced...

During an installation of  Quickr Services for Websphere Portal, I ran into the follow error when uploading content from the Connectors:

"RepositoryException: Error while calling a function createItems of PLS data manager."

I discovered that there isn't much out there when searching for this. After some further investigation, we discovered that a mount point was getting full. Since we were installing this on Linux, I made sure that all of my mount points looked alright - per the Quickr InfoCenter:

• /: 1.5 GB or more (root directory)
• /opt: 4 GB or more. The default directory to install Lotus Quickr on Linux is /opt, which you could change to any directory you like later. By default, /opt is under / file system in default. If you choose to install Lotus Quickr under /usr, 5 GB or more is recommended.
• /home: 700 MB or more (home directory)
• /tmp: 600 MB or more. Run the following command to ensure that you have appropriate permissions in the /tmp directory: ls -ld /tmp. The result should look like the following: drwxrwxrwt 34 root root 4096 date_stamp time_stamp/tmp.

The box was setup with /local mounted to a hefty internal disk array, so we used /local in place of /opt for the directory where we would install Quickr. This is where everything from the installation should go, right? Wrong.

Our /home path was only 2GB and it filled up rather quickly. When performing the installation, a "quikradm" account is created. This is the owner of the DB2 information, and all of the DB2 data will reside in the home path for this user account! Since Quickr is only supported on RHEL4 currently, we couldn't resize that mount point on the fly. So after a quick reboot and resizing of the /home path (to 3GB), we were able to get up and running. At that point, we went through the process of using the db2relocatedb command to move the DB2 information over to the /local path.

So, how do you prevent this? I haven't tested this, but I imagine that by first creating the db2 user account with the proper home directory that the installation will see the existing account (and therefore install the DB2 data into that home path!).