Mercurial > notdcc
view dblist.0 @ 2:f6716cb00029
Replace buggy stuff in deb dir, never make phone calls while working
author | Peter Gervai <grin@grin.hu> |
---|---|
date | Tue, 10 Mar 2009 14:29:12 +0100 |
parents | c7f6b056b673 |
children |
line wrap: on
line source
dblist(8) Distributed Checksum Clearinghouse dblist(8) NNAAMMEE ddbblliisstt -- Database List Distributed Checksum Clearinghouse SSYYNNOOPPSSIISS ddbblliisstt [--vvVVHHDD] [--GG _o_n | _o_f_f] [--hh _h_o_m_e_d_i_r] [--ss [_s_e_r_v_e_r_-_I_D][_,_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t]] [--CC _'_t_y_p_e _h_1 _h_2 _h_3 _h_4_'] [--II _s_e_r_v_e_r_-_I_D] [--AA _d_b_a_d_d_r] [--LL _p_a_t_h_l_e_n] [--PP _p_a_g_e_s] [--TT _t_i_m_e_s_t_a_m_p] [_f_i_l_e_1 _f_i_l_e_2 _._._.] DDEESSCCRRIIPPTTIIOONN DDbblliisstt lists the contents of a DCC database as it does some consistency checking. --vv lists more of the database. Additional information is produced with additional --vv arguments. --VV displays the version of the DCC database lister. --HH turns off the listing of the hash table as well as the analysis of the hash table. Determining the worst case and average lengths of chains in the hash table can take a long time for a large database on a small computer. --DD turns off the listing of the data or checksum records. --GG _o_n lists a greylist database. --hh _h_o_m_e_d_i_r overrides the default DCC home directory, _/_v_a_r_/_d_c_c. --ss [_s_e_r_v_e_r_-_I_D][_,_s_e_r_v_e_r_-_a_d_d_r][_,_s_e_r_v_e_r_-_p_o_r_t] somewhat quiets the DCC server process, dccd(8), to get somewhat more consistent results. _s_e_r_v_e_r_-_I_D must be in the _i_d_s file. _s_e_r_v_e_r_-_a_d_d_r and _s_e_r_v_e_r_-_p_o_r_t are the IP address and UDP port at which the server process listens. --CC _'_t_y_p_e _h_1 _h_2 _h_3 _h_4_' limits the listing to records containing that checksum or one of the other checksums specified with --CC. If the four hexadecimal values _h_1 _h_2 _h_3 _h_4 are absent, records with the matching _t_y_p_e will be listed. If _t_y_p_e is absent, any checksum with the four hexadecimal values will be listed. As many as 16 checksums can be specified. --II _s_e_r_v_e_r_-_I_D limits the listing to records with that server-ID or one of the other server-IDs specified with --II. As many as 16 server-IDs can be specified. --AA _d_b_a_d_d_r excludes database records before _d_b_a_d_d_r. --LL _p_a_t_h_l_e_n excludes records with path lengths shorter than _p_a_t_h_l_e_n. --PP _p_a_g_e_s ignores all but the last _p_a_g_e_s of the database. --TT _t_i_m_e_t_a_m_p excludes records with other timestamps. A timestamp with a missing microsecond value matches any record with that second. As many as 16 timestamps can be specified. _f_i_l_e_1 _f_i_l_e_2 _._._. are names of databases to be listed. The default is _d_c_c___d_b and its companion, _d_c_c___d_b_._h_a_s_h 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 performance of the hash are displayed. With a single --vv, most of the mail database file and the contents of mem- ory mapped server flooding positions in the _f_l_o_d_._m_a_p 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 _f_l_o_d_._m_a_p 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 _1_6_0_1 at about 8:25 UTC 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 password that the server recognized or authenti- cated. The report was then sent or `flooded' to the server with server- ID _1_0_1 which in turn sent it to a server with server-ID _1_0_3. That server sent it to the local DCC server. The record is at the address _0_x_2_f_e_5_b_9_4 in the database. The record contains 3 checksums. The simple checksum of the body of the message was _e_2_d_3_f_9_6_a _c_6_5_a_e_a_0_1 _3_f_e_c_e_3_6_1 _e_d_f_f_9_e_c_f 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 _0_x_2_f_2_1_3_6_4. The hash table entry for this body checksum is at _0_x_7_7_2_d_2. This report included two fuzzy checksums. Both have been previously reported as having been sent to _m_a_n_y targets. An asterisk (*) before the name of the checksum would indicate that a later record in the database makes this checksum redundant. A report of _m_a_n_y addressees makes all preceding reports redundant. The string _t_r_i_m_m_e_d after the server-ID marks older reports that have had uninteresting checksums removed. The string _c_o_m_p_r_e_s_s_e_d after the server- ID would indicate that this older report has been trimmed and compressed with older reports. With two --vv arguments, records added to the database by dbclean(8) from the server whitelist are also displayed. Three --vv 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 _0_x_1_9_b_8 is unused or free. Slot number _0_x_1_9_b_9 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 _0_x_1_9_c_0. The corresponding _F_u_z_1 checksum is at _0_x_9_0_1_2 in the database. The third slot at _0_x_1_9_b_a is also that of a _F_u_z_1 checksum, but it is not part of a hash chain and its data- base record is at _0_x_1_b_7_2_3_0_0. FFIILLEESS /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. SSEEEE AALLSSOO cdcc(8), dcc(8), dbclean(8), dccd(8), dccifd(8), dccm(8), dccproc(8). HHIISSTTOORRYY Implementation of ddbblliisstt was started at Rhyolite Software, in 2000. This document describes version 1.3.103. February 26, 2009