Prev
Next
Forums Infor / Lawson Platforms S3 Systems Administration

Problem switching from one ITDS server to another

 3 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
Tim
Basic Member
Posts: 6
Basic Member
9/11/2009 8:58 AM

    Hello,

    I'm hoping someone's got a quick solution to a problem I ran into tonight.

    I am getting a message in my lase.log ("Could not get identity for Login root for service xxxx") following a simple move of data from one ITDS server to another.  Here's what I have done:

    1. Shutdown Lawson environment
    2. Dump ITDS data from ITDS server A
    3. Load ITDS data  to ITDS server B
    4. Configure Lawson environment to reference ITDS server B
    5. Start Lawson environment

    All components of the environment seem to start, and I can connect using the Lawson Security Administrator tool, but when I attempt to 'Manage Identities" from within User Management, I get an error.  In the lase.log, when the environment is started, I get the following:

    09/11/2009 03:30:00 getuserenv: Pid 713160
    713160: Could not get identity for Login root for service xxxxxx
    713160: Error number  = 1
    713160: Error message = Lawson Security Error: Please check log files for detail
    s
    Error: Cannot get Identity. Original Exception: Invalid Argument (USER=null).
    713160: UserName = root

    If I reverse the Lawson environment configuration to reference ITDS server A, everything is fine.

    Any suggestions or ideas?  I want to say that I've seen this error before, but I just can't put my finger on it.

    Thanks in advance!

    -Tim

    Alex Tsekhansky
    Veteran Member
    Posts: 92
    Veteran Member
    9/11/2009 1:40 PM
      I think the key here is "Dump ITDS data" and "Load ITDS data".
      How did you do it?
      Did you copy the custom schema definition?
      Tim
      Basic Member
      Posts: 6
      Basic Member
      9/11/2009 3:25 PM
        With the environment down, we dump the data using db2ldif, then load it using ldapmodify. We did also load the schema.ldif using ldapmodify.

        There were no reported errors during the load, and in a side-by-side eyeballing of the data, it looks like everything is there.
        Alex Tsekhansky
        Veteran Member
        Posts: 92
        Veteran Member
        9/12/2009 2:55 AM
          I am guessing here, but I think the issue is with the schema. You can manually compare a few attributes of the user-related objects in both LDAPs.
          Where do you get schema.ldif? Was it produced by db2ldif? If yes - are you sure it dumped definitions of the custom attributes lawson creates?
          The fact that there were no errors during the load does NOT mean that things were loaded correctly. LDAPMODIFY does implicit conversion from text-based data into whatever "special" datatypes exist in the LDAP repository.
          I think that the best way to duplicate Tivoli would be either dbrestore or replication.
          That would GUARANTEE you the same object types and data, without going through an implicit conversion process.