Conference forty2::x500

    The error 'DSA is unavailable' is generated by infobroker when it
    finds an attribute that it doesn't like. It is indeed a very misleading
    error !
    
    I am not sure what the trace is saying, but it may indicate that
    infobroker does not know anything about that attribute.
    
    Andrew

    Andrew,
    
    The ibxd should know about the attribute - it is using the same schema
    files as the DSA; isn't it ?   When we use another UMICH tool ;
    ldapsearch it DOES recognise the attribute.  On lookup; there is NO
    problem at all; it's only on modification that the problem appears.
    Modification via LDAP of course; via dxim command line : no problem.
    
    (Don't know if you've ever used it - but here's the UMICH utility that
     we use :)
    
       ldapsearch  bcPwdExpirationDate=*   
    
       (equivalent to dxim -c :   'search where bcPwdExpirationdate=*')
    
    this LDAP utility sends a request to the ibxd and it correctly returns
    all entries which have a value for
    this attribute (have been initialised via DXIM).  The representation is
    the one we expect (YYYYMMDDHHMMSS.HHHZ) for an attribute with this
    syntax ; btw the same as for modify- and createTimeStamp.
    
    But when we try to modify our attribute, there seems to be a problem in
    ibxd (our guess !).
    We guess that ibxd cannot deal with all syntaxes and/or types; hence
    the ROSE error.
    
    I'm pretty sure that when we change the syntax to printableString (or
    something of the like) that the problem will disappear.  But we're very
    reluctant of doing this.   The attribute DOES represent a timestamp
    after all ...
    
    We would like to find out if there 's a problem with the conversion
    that ibxd has to do from the LDAP string representation of 
    generalizedTimeSyntax to the DAP representation.
    
    Does this make any sense ?
    
    /Roger.  (Working on this with Dominique)
    
    

The trace shows a message
Modtype 'bcPwdExpirationDate' matches nothing

I think you need to find what this message means (possibly it
means that the attribute is unknown, or possibly that there is
no matching rule for that attribute).

The ROSE reject may indicate that infobroker has sent some
bad DAP to the DSA, possibly because it could not provide
a good OID.

I think that infobroker is trying to build a DAP Read request,
to determine what attributes are already present in the entry.
So it would not have had to convert the value of this attribute
yet.

You need to get somebody to look at the infobroker sources here
(I dont have easy access to them).

Andrew

I just looked at the sources.

The 'matches nothing' message means that infobroker did not
find that the entry contained the attribute. So it had already
done the read operation.

The ROSE error is probably because it converted the generalized
time badly.

A trace on the dsa would show what the converted data was.

ncl> test dsa command "set trace osul=12"
do the test
ncl> test dsa command "set trace all=0"

then look in /var/dxd/dsa_output.log

Andrew

    The part of interest of the trace is the following.
    1997010101... represent the generalised time to be Updated on the DSA.
    
Copyright Digital Equipment Corporation 1993, 1997. All rights reserved
Version V3.1-5

        
25:osul_send(port=15208): entry point
25:osul_send(port=15208): exit point
25:Osul: Deallocating an OSAK buffer
25:Osul: Deallocating an OSAK buffer
11:osul_recv: select(port.fd=10) completed
11:osul_recv: osak_get_event(port.fd=10) completed with status 44740609
11:osul_recv: upper-layer PCI buffer list = NULL
11:osul_recv: user-data buffer list = 74158->NULL
11:osul_recv(port=15208): exit point - event = P-DATA indication
11:Processor: Received DAP pdu octets at Tue Jun  3 08:04:14 1997
        61 81 d3 30 81 d0 02 01 03 a0 81 ca a1 81 c7 02    a  0            
        01 00 02 01 08 31 81 be a0 3c 30 3a 31 11 30 0f         1   <0:1 0 
        06 03 55 04 0a 13 08 42 65 6c 67 61 63 6f 6d 31      U    Belgacom1
        0c 30 0a 06 03 55 04 07 13 03 54 42 52 31 17 30     0   U    TBR1 0
        15 06 0b 2b 18 0a 0b 20 02 fa ff 1b 01 01 13 06       +            
        39 39 32 34 30 36 a1 6e 30 6c a1 05 06 03 55 04    992406 n0l    U 
        23 a0 12 30 10 06 03 55 04 23 31 09 04 07 48 65    #  0   U #1   He
        6c 6c 6f 32 37 a2 1a 30 18 06 0b 2b 18 0a 0b 20    llo27  0   +    
        02 fa ff 1b 01 24 31 09 04 07 48 65 6c 6c 6f 32         $1   Hello2
        36 a1 0d 06 0b 2b 18 0a 0b 20 02 fa ff 1b 01 21    6    +         !
        a0 24 30 22 06 0b 2b 18 0a 0b 20 02 fa ff 1b 01     $0"  +         
        21 31 13 31 39 39 37 30 31 30 31 30 31 30 31 30    !1 1997010101010
        31 2e 30 30 30 5a be 0e 31 0c a0 05 03 03 07 80    1.000Z  1       
        00 a4 03 02 01 00                                        
        
        
11:Processor: request pdu is 1.0
11:osul_recv(port=15208, timeout=0, allow_obf=0): entry point
11:osul_recv: called osak_give_buffers
11:osul_recv: osak_get_event(port.fd=10) completed with status 44741651
11:osul_recv: select(port.fd=10) called
25:Processor: sending DAP response pdu octets for 1.0 at Tue Jun  3 08:04:14 1997
        61 0f 30 0d 02 01 03 a0 08 a4 06 02 01 00 80 01    a 0             
        02                                                  
        
        
25:osul_send(port=15208): entry point
25:osul_send(port=15208): exit point
25:Osul: Deallocating an OSAK buffer
25:Osul: Deallocating an OSAK buffer
11:osul_recv: select(port.fd=10) completed
11:osul_recv: osak_get_event(port.fd=10) completed with status 44740609
11:osul_recv: upper-layer PCI buffer list = 741a0->NULL
11:osul_recv: user-data buffer list = NULL
11:osul_recv(port=15208): exit point - event = A-RELEASE indication
11:Osul: Deallocating an OSAK buffer
11:osul_release_connection(port=15208): entry point
11:osul_recv(port=15208, timeout=30, allow_obf=0): entry point
11:osul_recv: time limit = 30
11:osul_recv: called osak_give_buffers
11:osul_recv: osak_get_event(port.fd=10) completed with status 44741651
11:osul_recv: select(port.fd=10) called
11:osul_recv: select(port.fd=10) completed
11:osul_recv: osak_get_event(port.fd=10) completed with status 44740609
11:osul_recv: upper-layer PCI buffer list = NULL
11:osul_recv: user-data buffer list = NULL
11:osul_recv(port=15208): exit point - event = Transport Disconnect
11:osul_release_connection(port=15208): transport disconnect received (event=135)
11:osul_release_connection(port=15208): exit point
11:osul_release_port(port=15208): entry point
11:Osul: Deallocating an OSAK buffer
11:osul_release_port: destroying port structure
11:osul_release_port(port=15208): exit point
    

It appears as if infobroker is assuming that the data for the
attribute value is already encoded in asn1. I think this is
actually the correct thing to do for generalised time syntax.

Infobroker should also be returning attributes of generalised
time syntax to the application in this form. I.e. you should get
2 octets of asn1 tag/length at the start of the value.

Normal strings do not have the asn1 tag/length at the start of
the value.

Andrew

    Andrew,
    
    I can tell you (as I already mentioned in .2, I believe) that in the
    opposite direction all goes well.
    This means that Infobroker does the text string conversion and we do
    NOT receive a BER - encoded value in TLV format.
    
    RFC1778 (section 2.21 specifies for UTC Time; so NOT for
    generalisedTime)
    
    	" Values of type uTCTimeSyntax are encoded as if they were
    	  Printable Strings with the strings containing a UTCTime value "
    
    Now : uTCTimeSyntax doesn't differ that much from generalisedTimeSyntax ;
    only in the fractions of a second and in the visualisation of the 
    century number   (19970603123344.222Z gen.Time  vs.  970603123344Z uTC)
    I would have expected the same behaviour for both.   
    
    The Belgacom attributes containing time stamps were defined with the
    year 2000 in mind; hence generalisedTimeSyntax  ;-)
    
    Since the opposite direction seems to work and because of the
    rule for uTCTimeSyntax in RFC1778, isn't it more logical to do the
    same for generalisedTimeSyntax ?
    
    /Roger.  

The rules for LDAP are not well thought out, and dont appear to 
be logical. UTC time and Generalised Time are not the same syntax,
even though they carry roughly the same information. RFC 1778
mentions some syntaxes (including UTC time) explictly, and
implicity says that everything else should be treated as 'undefined
syntax'. I would agree that treating Generalised Time as a string
syntax would be in the spirit of RFC 1778, but it does seem to go
against the text.

Infobroker should, however, expect the same syntax that it gives out.
Try modifying the create time stamp, using the same value that you 
received, and see what error happens. If the RORJ message appears
then it would seem that infobroker is not consistent. You should
then raise this as a support problem against infobroker.

You could also try reading these attributes with some other LDAP
server, to see how other people interpret this.

I would agree that Generalised Time should be used in preference
to UTC time.

Andrew

    Thanks Andrew - I think we're getting there.
    
    >I would agree that treating Generalised Time as a string
    >syntax would be in the spirit of RFC 1778, but it does seem to go
    >against the text.
    
    OK, but then Infobroker should do it in both directions !
    One of the very first things we've tried is to input the value (string
    rep) that we 've got from Infobroker.  The ROSE error appears ...
    So, I have the impression that it should work with 'undefined syntax'
    in both directions (read and write) or with a string representation;
    but not one for reading and the other for writing ...
    
    Before I decided to use generalisedTimeSyntax I did try with the
    modifyTimeStamp and createTimeStamp attributes.   Since they were
    presented to me (by Infobroker) as a text string and NOT as a BER
    encoded value (undefined syntax) I (foolishly) assumed that I could
    write my new attribute with generalisedTimeSyntax ...
    
    We currently do NOT have another LDAP server (other than Infobroker) at
    Belgacom, so it's difficult to compare with other implementations.  But
    I guess ours should be display consistant behaviour, no ?
    
    Can you specify in which direction (unspecified syntax or string) this
    problem will (or can) be solved ?
    
    Thx.
    /R. 

I agree that it should be consistent. You will have to raise an
infobroker support problem to get this resolved.

For the record, AltaVista Directory treats generalised time as
an undefined syntax in both directions. (That doesn't make it the
'correct' thing to do though !).

LDAP V3 tries (and probably fails) to solve this problem.

Andrew

    Andrew,
    
    OK.  Dany Cuyt will take care of submitting this support problem.
    
    Thanks for your involvment.
    /R.