Bug 304191 - dbscan doesn't handle RUV entries in changelog db
Summary: dbscan doesn't handle RUV entries in changelog db
Alias: None
Product: 389
Classification: Retired
Component: Command Line Utilities
Version: 1.1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
Depends On:
Blocks: 240316 FDS1.1.0
TreeView+ depends on / blocked
Reported: 2007-09-24 22:04 UTC by Nathan Kinder
Modified: 2015-12-07 16:59 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:59:37 UTC

Attachments (Terms of Use)
CVS Diffs (2.52 KB, patch)
2007-09-24 22:04 UTC, Nathan Kinder
no flags Details | Diff
Revised Diffs (3.38 KB, patch)
2007-09-24 23:38 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2007-09-24 22:04:38 UTC
If you try to run the dbscan tool against a changelog db on a stopped server, it
reports the an error similar to:

    dbid: 0000006f000000000000
    Invalid changelog db version 1
    Works for version 5 only.

The print_changelog function in dbscan.c expects all entries to have 0x05 as the
first byte, which signifies the changelog version.  This version check should be
done for all change entries in the changelog db, but there are three special
entries that are in the beginning of the changelog where this doesn't apply. 
These entries are an entry count, the purge RUV, and the max RUV.

It should be noted that these entries are not always present when the server is
running, so dbscan will often work fine against a running server.  When the
server is stopped gracefully, these entries are flushed out to be used once the
server is restarted. 

The attached diffs make dbscan check for these special entries when reading
through a changelog.  If it encounters one of these entries, it will print out
the data in a nice usable format.  Here is an example of the output for these
three entries with my changes:

dbid: 0000006f000000000000
        entry count: 5

dbid: 000000de000000000000
        purge ruv:
                {replicageneration} 46f806a2000000030000
                {replica 3 ldap://snail.example.com:389}
                {replica 1 ldap://snail.example.com:389}

dbid: 0000014d000000000000
        max ruv:
                {replicageneration} 46f806a2000000030000
                {replica 3} 46f808dc000100030000 46f808dc000100030000
                {replica 1} 46f812b2000000010000 46f813cf000000010000

Comment 1 Nathan Kinder 2007-09-24 22:04:38 UTC
Created attachment 204611 [details]
CVS Diffs

Comment 2 Rich Megginson 2007-09-24 22:51:57 UTC
Looks good.  You should probably put a comment near the definition of
ENTRY_COUNT_KEY etc. explaining where these values come from in cl5_api.c.

Also, it looks as though there is a bug in cl5ReadBervals().  In your code, you
use ntohl to read the number of bervals.  But in the cl5 code, it uses PR_htonl
to read this value.  This is not correct because it uses PR_htonl to encode the

Comment 3 Noriko Hosoi 2007-09-24 23:08:43 UTC
This is also in cl5_api.c. :)  If you have a chance to fix the bug that Rich
pointed out above, could you add (time_t) before passing type to csn_set_time?

static char* _cl5GetHelperEntryKey (int type, char *csnStr)
    CSN *csn= csn_new();
    char *rt;
    csn_set_time(csn, type); <=== type: cast to time_t.

void csn_set_time(CSN *csn, time_t csntime)
    csn->tstamp= csntime;

struct csn
    time_t tstamp;

Comment 4 Nathan Kinder 2007-09-24 23:38:07 UTC
Created attachment 204671 [details]
Revised Diffs

These revised diffs address the two issues that Rich and Noriko raised.

Comment 5 Nathan Kinder 2007-09-24 23:40:09 UTC
Checked into ldapserver (HEAD). Thanks to Rich and Noriko for their reviews!

/cvs/dirsec/ldapserver/ldap/servers/plugins/replication/cl5_api.c,v  <--  cl5_api.c
new revision: 1.16; previous revision: 1.15
Checking in slapd/tools/dbscan.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/tools/dbscan.c,v  <--  dbscan.c
new revision: 1.17; previous revision: 1.16

Note You need to log in before you can comment on or make changes to this bug.