Home

Results 1 to 3 of 3

Thread: Problem with createTimestamp attribute

  1. #1
    Join Date
    Aug 2015
    Posts
    2

    Problem with createTimestamp attribute


    Hi everybody,

    I am facing an issue which is very anoying since I didn't do anything
    particularly to have it.
    "
    My problem is that each time I create or modify an object in my
    eDirectory, the createTimestamp and modifyTimestamp are initialized to
    "5 fvr. 2106 07:28:15 CET (21060205062815Z)".

    Note that my eDirectory version is : "NetIQ eDirectory 8.8 - 8.8 SP8
    v20806.02" running on a "Red Hat Enterprise Linux Server release 6.6
    (Santiago)".

    I verified the time on the server and it's good, however, when i run a
    "ndsrepair -R" i have many errors like this one :


    Code:
    --------------------
    ERROR: Illegal timestamps were found in this replica.
    You may need to run 'Repair Timestamps'
    Value: fffd5cff, ID: 000080a3, DN: OU=FR.O=ONAME.T=NAME-TREE
    Time stamp: February 04, -50 06:28:15 AM
    ; rep # = 0001; event = 6b91

    --------------------


    I really don't know how to repair this since the only way I found to
    solve this is to do a "ndsrepair -P -Ad" then select the replica and
    then select Replica Options, Repair Time Stamps and Declare a New Epoch.

    I am not sure about this command and this is a really hard command for a
    problem which seems easier.

    What do you think ? Have you got an idea on how to solve this ?

    Thanks


    --
    vpihen
    ------------------------------------------------------------------------
    vpihen's Profile: https://forums.netiq.com/member.php?userid=5615
    View this thread: https://forums.netiq.com/showthread.php?t=54094


  2. #2

    Re: Problem with createTimestamp attribute

    1. Declaring an Epoch is serious business, and a last resort. With that
    said, when you have time issues of more than a day or so, it's often done
    just so you can get on with life. You're off by 91 years, so maybe that
    is the only way to go in your case.

    2. When you wrote, "...the only way I found to solve this is to [declare
    an epoch]" does that mean you have already done that, and the problem came
    back? If that is the case, you have not fixed the root cause and that
    must be done first. Typically the root cause is simple: a server out of
    time sync. When a server gets something to do, it timestamps the
    objects/attributes modified so that the change cache can see these as new
    (relative to other servers' timestamps) and then the changes will be sent.
    When a server's time is in the year 2106 and you fix the time to now be
    in 2015, nothing you do today is newer than what happened in the past so
    objects can become stuck in a more-current (i.e. future) state until that
    future time is reached, in your case in ninety-one years or so. The epoch
    is done to reset timestamps in a sense, but that is why it is a big operation.

    If you have a server out of sync with the rest of the world's time, you
    need to fix that first. The hardest part about this is that it may not be
    a server you think is in the tree. For example:

    a. You cloned a box for a test environment. You even think you isolated
    it, but you did not do it well enough so not it is talking to the
    production tree acting as one of your servers in production, and since it
    now has a time issue, it's doing bad things for you. That non-production
    server needs to be stopped.

    b. You decommissioned a server, even powered it off, and then the guy in
    the next desk over turned it on without realizing eDirectory servers were
    still there. Due to bad luck, that box has a time issue.

    c. A proper production box has a hardware issue, so its time is all over
    the place, jumping forward and backward. Luckily things are not crashing,
    but unluckily time-sensitive things (like replication) are being
    negatively impacted.

    If you look at these timestamps in iMonitor, there should be three parts;
    those parts are a date/time we recognize, then a couple of integers as
    well, for example:
    20150819090500#1#234

    or maybe the first timestamp will be in unixtime, in which case:
    1439996736#1#234

    The second integer, '1' above', indicates the replica number where the
    timestamp was written as I recall. If you then look at the partition root
    for this object (perhaps the [root] of the tree, but perhaps not depending
    on your partitioning) you can see a Replica(s) attribute which lists all
    of the servers and their replica types along with replica numbers. Find
    the attribute indicating it is replica #1, and that box, or one
    impersonating it, is/was probably the culprit with time issues.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  3. #3
    Join Date
    Aug 2015
    Posts
    2

    Re: Problem with createTimestamp attribute


    ab;259985 Wrote:
    > 1. Declaring an Epoch is serious business, and a last resort. With
    > that
    > said, when you have time issues of more than a day or so, it's often
    > done
    > just so you can get on with life. You're off by 91 years, so maybe
    > that
    > is the only way to go in your case.
    >
    > 2. When you wrote, "...the only way I found to solve this is to
    > [declare
    > an epoch]" does that mean you have already done that, and the problem
    > came
    > back? If that is the case, you have not fixed the root cause and that
    > must be done first. Typically the root cause is simple: a server out
    > of
    > time sync. When a server gets something to do, it timestamps the
    > objects/attributes modified so that the change cache can see these as
    > new
    > (relative to other servers' timestamps) and then the changes will be
    > sent.
    > When a server's time is in the year 2106 and you fix the time to now be
    > in 2015, nothing you do today is newer than what happened in the past
    > so
    > objects can become stuck in a more-current (i.e. future) state until
    > that
    > future time is reached, in your case in ninety-one years or so. The
    > epoch
    > is done to reset timestamps in a sense, but that is why it is a big
    > operation.


    I didn't do that for now, i wanted to be sure that there were no other
    solutions before doing this "big operation".

    ab;259985 Wrote:
    > If you have a server out of sync with the rest of the world's time, you
    > need to fix that first. The hardest part about this is that it may not
    > be
    > a server you think is in the tree.


    All servers are well time sync according to "ndsrepair -T" :

    ---------------------------+---------+---------+-----------+--------+-------
    DS Replica Time Time is
    Time
    Server name Version Depth Source in sync
    +/-
    ---------------------------+---------+---------+-----------+--------+-------
    Processing server: .one.Ressources.company
    ..one.Ressources... 20605.01 2 Non-NetWare Yes 0
    Processing server: .two.Ressources.company
    ..two.Ressource... 20806.06 0 Non-NetWare Yes 0
    Processing server: .three.Ressources.company
    ..three.Ressources.... 20605.01 0 Non-NetWare Yes
    0
    Processing server: .four.Ressources.company
    ..four.Ressource... 20806.06 0 Non-NetWare Yes 0
    ---------------------------+---------+---------+-----------+--------+-------
    Total errors: 0


    ab;259985 Wrote:
    >
    >
    > a. You cloned a box for a test environment. You even think you
    > isolated
    > it, but you did not do it well enough so not it is talking to the
    > production tree acting as one of your servers in production, and since
    > it
    > now has a time issue, it's doing bad things for you. That
    > non-production
    > server needs to be stopped.


    This environment is a fresh new environment, it is not a copy of another
    environment.

    ab;259985 Wrote:
    > b. You decommissioned a server, even powered it off, and then the guy
    > in
    > the next desk over turned it on without realizing eDirectory servers
    > were
    > still there. Due to bad luck, that box has a time issue.


    I didn't decommissioned any server.

    ab;259985 Wrote:
    > c. A proper production box has a hardware issue, so its time is all
    > over
    > the place, jumping forward and backward. Luckily things are not
    > crashing,
    > but unluckily time-sensitive things (like replication) are being
    > negatively impacted.


    The time on the server is good.

    ab;259985 Wrote:
    > If you look at these timestamps in iMonitor, there should be three
    > parts;
    > those parts are a date/time we recognize, then a couple of integers as
    > well, for example:
    > 20150819090500#1#234
    >
    > or maybe the first timestamp will be in unixtime, in which case:
    > 1439996736#1#234
    >
    > The second integer, '1' above', indicates the replica number where the
    > timestamp was written as I recall. If you then look at the partition
    > root
    > for this object (perhaps the [root] of the tree, but perhaps not
    > depending
    > on your partitioning) you can see a Replica(s) attribute which lists
    > all
    > of the servers and their replica types along with replica numbers.
    > Find
    > the attribute indicating it is replica #1, and that box, or one
    > impersonating it, is/was probably the culprit with time issues.


    Where can i find these timestamps you are talking about ?

    Thanks for your help.


    --
    vpihen
    ------------------------------------------------------------------------
    vpihen's Profile: https://forums.netiq.com/member.php?userid=5615
    View this thread: https://forums.netiq.com/showthread.php?t=54094


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •