Our vBulletin migration is complete.
Welcome vBulletin users! All content and user information from the Micro Focus Forums (vBulletin) site has been migrated to this site. READ MORE.
vpihen Absent Member.
Absent Member.
421 views

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 févr. 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

Labels (1)
0 Likes
2 Replies
Knowledge Partner
Knowledge Partner

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...
0 Likes
vpihen Absent Member.
Absent Member.

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

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.