I like blogging such stories about strange incidents in customers :) I hope it helps my newbie readers to learn how to troubleshoot these kind of problems.
Today I made a short visit to a customer to chat. A couple of weeks ago, we struggled with some SSO issues between Domino and Portal. It seems that 'Reset Password' feature of ID Vault was not working since SSO operation. I told them there is absolutely no relation between two issues. I were so sure :)
Last year, the most popular topic in my blog was the one related to ID Vault problems. The reason is obvious. There are some 'nice to have' features that people try out implementation but in case of failure, they may just give up. However, ID Vault is an extremely useful tool that cannot be avoided...
I assumed this to be a classical issue, as well. I checked everything, from public keys to ACLs but it was OK. I recreated cross certifications, tried different users, etc. Nope! ID Vault was giving the classical error: "Missing or invalid Password Reset Trust certificate from 'XXX' to 'YYY': Note Item not found".
Here, I noticed a difference. The classical error may end with 'Entry not found in Index'. Because, normally, the problem originates from a missing certificate document.
So I opened some debug parameters (Debug_IDV_TrustCert=1; Debug_Namelookup=1) and the problem was there smiling at me :)
For password reset operation, there are cross certification documents for each resetters. For example, if an administrator (John May/Acme) will reset password of a user (Mary Jane/Acme), there should be a cross-certification document (O=Acme >> John May/Acme) for password reset operations. Server will find this document first and validate it with the organization certifier. An example:
[0B30:009A-0CC4] NAMELookup:: Searching view '($Users)' (1 of 1 views). [0B30:009A-0CC4] NAMELookup:: Searching name='O=Acme' (1 of 1 names). [0B30:009A-0CC4] NAMELookup:: Searching DBIndex=1. [0B30:009A-0CC4] NAMELookup:: NumReturned=0, TotalNumReturned=0 match(es) for name='O=Acme'
In this case, it could not find the certifier document (entry not found in index). In my case, though:
[0B30:009A-0CC4] NAMELookup:: Searching view '($Users)' (1 of 1 views). [0B30:009A-0CC4] NAMELookup:: Searching name='O=Acme' (1 of 1 names). [0B30:009A-0CC4] NAMELookup:: Searching DBIndex=1. [0B30:009A-0CC4] NAMELookup:: NumReturned=2, TotalNumReturned=2 match(es) for name='O=Acme'
There were two matches in the address book. I just checked with '($Users)' view and that was correct. There were a person document with 'O=acme' line in shortname field!
Probably we made a mistake while dealing with the SSO issue. It can be fatal to place your certifier name into an alias :)
I am a bit flushed... But the problem has been solved...
Two critical HTTP problems in Domino 9...
Fri, Mar 29th 2013 6:48a Serdar Basegmez After I upgraded my servers to Domino 9, I have found two problems affecting HTTP task. 1. Redirect TCP to SSL problem... My HTTP task stopped responding just after the upgrade. When I look into thread logs I saw that it was redirecting every requests to the same URL! After a couple of tests, I found that if you have "Redirect TCP to SSL" checked in your Internet Site document, it fails with infinite redirection problem. I posted the issue into the N/D 9.0 Social Edition forum and [read] Keywords: administration
Happy Pi Day present: Pi Calculator for XPages...
DOTS Deep Dive 4: I can schedule myself...
Thu, Feb 21st 2013 5:20a Serdar Basegmez Finally, we will be able to enable FeedMonster for CollaborationToday project. While doing final touches, I have been challenged by a question: "Can we schedule DOTS tasklets programmatically?" Actually, this is in the wish list for the next version of DOTS. But we can do some trick here. I didn't test this on Domino 9 but it should work. Here is the code: package org.openntf.news.playground.tasklets; import org.eclipse.core.runtime.CoreException; import org.eclipse.core [read] Keywords: domino
DOTS Deep Dive 3: Warning for Deadlocks
Thu, Feb 14th 2013 7:03a Serdar Basegmez Last time, I have blogged about the importance of the importantance of canceling tasklets... In most of the time, canceling a task is a 'choice' you have. You might want to stop the task for a reason. However, a very important problem is falling into deadlocks. If somehow your code falls into a deadlock or stuck situation, that would lock your DOTS container entirely. DOTS uses a basic mechanism for identifying scheduled tasklets that are stuck. Every tasklet starts its life with a pre [read] Keywords: ibm
DOTS Deep Dive 2: Cancel me or I will crash your server...
Wed, Feb 13th 2013 3:53a Serdar Basegmez I just wanted to emphasize an important functionality within DOTS... One of our slides in the recent DOTS session in IBM Connect 2013, we have talked about the "monitor" argument in tasklets. It has two important uses. First of all, you might let DOTS container know about your progress. Second, it allows you to cancel your task in a less-disruptive manner. Let's dive into code here. Our tasklet is running every five seconds and wait 30 seconds each run: @RunEvery( every=5, [read] Keywords: domino
DOTS Deep Dive 1: Art of Scheduling Tasklets
Mon, Feb 11th 2013 4:02a Serdar Basegmez After a successful IBM Connect session, I started a series of posts, based on feedbacks I received from other developers. There was a little thing I didn't test before the session and this issue has been asked a couple of times: Possible conflicts between scheduled tasklets. Unfortunately, current implementation within DOTS is based on single threaded approach for tasklets. There are three different threads responsible in DOTS tasklet container for scheduled, manual and triggerred tasklet [read] Keywords: domino