Re: cn=monitor && CS&T calendar

[Justin Banks <justinb@wamnet.com>]

>>>>> "Rich" == Rich Graves <rcgraves@brandeis.edu> writes:

 Rich> On Tue, 5 Dec 2000, Justin Banks wrote:
 
 Rich> I didn't run into that problem. It "just worked," after I spent
 Rich> a couple hours figuring out v3 schemas. Outline
 Rich> http://www.openldap.org/faq/index.cgi?file=521

 Rich> What version of Calendar are you using? I have 5.1 on Linux.

The company currently has 3.5, and an upgrade (at least initially) is
not in the cards, alas. Perhaps that's my trouble. The real hurdle is
the lack of 'cn=monitor' availability, without which the unidasd
daemon reports 

DEXOTEK ERRCODE Ox18030 -> ctldap_Open: Interoperability error
DEXOTEK ERRCODE Ox18030 -> das_Open: das_OpenDirConnection
DEXOTEK ERRCODE Ox18030 -> das_trh_Open: das_Open
DEXOTEK ERRCODE Ox11201 -> unidasd daemon: received SIGTERM

and exits. 

 >> am I on my own here? Or, maybe I should take the easy route and
 >> move back to 1.2.5 or so (thereby wasting all my attribute
 >> definition effort), although I hate to move backwards.

 Rich> Newer versions of CS&T (now Steltor) require LDAPv3, so you
 Rich> can't move backwards.

Good. At least I have a reason to keep going forward ;)

My current tack is to define things as

attributetype ( foo-oid NAME 'foo'
                DESC 'foo (for CS&T calendar)'
                EQUALITY caseIgnoreMatch
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
              )

and I can then make the needed mods to monitor.c to get me past
this. Does anyone out there see a problem with this?

-justinb

-- 
Justin Banks - WAM!NET Inc., Eagan MN justinb@wamnet.com
#define private public  // Information hiding in C++?  Ha!