dblist(8)

NAME

dblist - Database List Distributed Checksum Clearinghouse

SYNOPSIS

dblist [-vVHD] [-G on | off] [-h homedir] [-C 'type h1 h2 h3
h4']
       [-I  server-ID]  [-A  dbaddr] [-L pathlen] [-P pages]
[-T timestamp]
       [file1 file2 ...]

DESCRIPTION

Dblist lists the contents of a DCC database as it does some

consistency checking.

-v lists more of the database. Additional information is

produced with additional -v arguments.

-V displays the version of the DCC database lister.

-H turns off the listing of the hash table as well as the

analysis of the hash table. Determining the worst case and aver

age lengths of chains in the hash table can take a long time for

a large database on a small computer.

-D turns off the listing of the data or checksum records.

-G on

lists a greylist database.

-h homedir

overrides the default DCC home directory, which is of

ten /var/dcc.

-C 'type h1 h2 h3 h4'

limits the listing to records containing that checksum

or one of the other checksums specified with -C or server-IDs

specified with -I. As many as 16 checksums can be specified.

-I server-ID

limits the listing to records with that server-ID or

one of the other server-IDs specified with -I or checksums speci

fied with -C. As many as 16 server-IDs can be specified.

-A dbaddr

excludes database records before dbaddr.

-L pathlen

excludes records with path lengths shorter than

pathlen.

-P pages

ignores all but the last pages of the database.

-T timetamp

excludes records with other timestamps. As many as 16

timestamps can be specified.

file1 file2 ...

are names of databases to be listed. The default is

dcc_db and its companion, dcc_db.hash in the DCC home directory.

By default, the sizes of the main file and the hash table as

well as how much they contain and values related to the perfor

mance of the hash are displayed.

With a single -v, most of the mail database file and the

contents of memory mapped server flooding positions in the

flod.map file are listed. The listing starts with the serial

number of the database file which is when old entries were last

removed from it by dbclean(8) That is followed by similar lines

showing the oldest timestamp of checksums not expired by dbclean

and of mail that is not "spam."

The flooding positions from the flod.map file are record

offsets or addresses in the main database file.

A typical record in the main database file looks like:

02/07/02 20:25:12.497032 5 auth 1601

2fe5b94

path: 103<-101<-1601

Body 6 e2d3f96a c65aea01 3fece361 edff9ecf

2f21364 772d2
Fuz1 many 6ff56fe8 ffc312d7 a5fe8f13 12a537ae

2f21364 200a9
Fuz2 many fac882b8 03eea34f bd792c40 2fe6fd54

2f21364 72816

That example was received by a DCC server with server-ID

1601 at about 8:25 GMT on the evening of February 7, 2000. The

report was about a mail message set to 5 addressees. The report

was from a client that presented a client-ID and matching pass

word that the server recognized or authenticated. The report was

then sent or 'flooded' to the server with server-ID 101 which in

turn sent it to a server with server-ID 103. That server sent it

to the local DCC server. The record is at the address 0x2fe5b94

in the database. The record contains 3 checksums. The simple

checksum of the body of the message was e2d3f96a c65aea01

3fece361 edff9ecf The total number of recipients of messages with

this body checksum known in the database is 6, which implies this

checksum had been previously reported with a target count of 1.

The previous report in the database of a message with this body

checksum is at 0x2f21364. The hash table entry for this body

checksum is at 0x772d2. This report included two fuzzy check

sums. Both have been previously reported as having been sent to

many targets.

An asterisk (*) before the name of the checksum would indi

cate that a later record in the database makes this checksum re

dundant. A report of many addressees makes all preceding reports

redundant.

The string trimmed after the server-ID marks older reports

that have had uninteresting checksums removed. The string

compressed after the server-ID would indicate that this older re

port has been trimmed and compressed with older reports.

With two -v arguments, records added to the database by db

clean(8) from the server whitelist are also displayed.

Three -v arguments cause the hash table to be displayed.

Three typical hash table entries look like:

19b8: 19ee 19b7
19b9: 19c0 0 90120 Fuz1
19ba: 0 0 1b72300 Fuz1

The entry in slot number 0x19b8 is unused or free. Slot

number 0x19b9 is the start of a chain of collisions or entries

with the same hash value of 0x19b9. The next slot in this chain

is at 0x19c0. The corresponding Fuz1

checksum is at 0x9012 in the database. The third slot at

0x19ba is also that of a Fuz1 checksum, but it is not part of a

hash chain and its database record is at 0x1b72300.

FILES

/var/dcc is the DCC home directory containing data and

control files.
dcc_db grey_dcc_db

main file of checksums.

dcc_db.hash grey_dcc_db.hash

database hash table.

flod.map grey_flod.map

memory mapped flooding positions.

SEE ALSO

cdcc(8), dcc(8), dbclean(8), dccd(8), dccifd(8), dccm(8),

dccproc(8).

HISTORY

Implementation of dblist was started at Rhyolite Software in

2000. This describes version 1.2.74.

BSD December 7, 2007

BSD