dblist(8)

📦 version 2.3.169, in alpine 3.24

💅 dblist(8) — the group chat version 🫶

okay so bestie, welcome to dblist, from the System Manager's Manual ✨ — it's the Database List tool for the Distributed Checksum Clearinghouse, and honestly? it's giving backstage-pass energy. you get to peek inside the DCC database while it does a little consistency check on the side. no cap. 👑

✨ 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, and while it's at it, it does some consistency checking too. multitasking icon behavior, honestly 💖

  • -v — lists more of the database. like, more more. every extra -v argument gives you additional information. stack 'em, bestie 🎀
  • -V — displays the version of the DCC database lister. two or more -V options show the options with which it was built. (yes, -V -V is the "and how were you built" arc 👀)
  • -H — turns off the listing of the hash table and the analysis of the hash table. heads up though: 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, so this is your escape hatch 😭
  • -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, /var/dcc. relocation era 💅
  • -C 'type h1 h2 h3 h4' — limits the listing to records containing that checksum, or one of the other checksums specified with -C. if the four hexadecimal values h1 h2 h3 h4 are absent, records with the matching type will be listed. if type is absent, any checksum with the four hexadecimal values will be listed. and if the hexadecimal values h1 h2 h3 h4 are absent, all checksums of the specified type will be listed. so many combos, main character flexibility ✨

the alternate form 'server-ID {simple|commercial|ignore|rogue} at ID' can be used to select server-ID records of some types. 🔥

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. as many as 16 server-IDs can be specified. 🦋
  • -A dbaddr — excludes database records before dbaddr. bye bye old stuff 👋
  • -L pathlen — excludes records with path lengths shorter than pathlen.
  • -P pages — ignores all but the last pages of the database. (only the freshest pages get to sit with us 💀)
  • -T timetamp — 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. ⏰
  • file1 file2 ... — are names of databases to be listed. the default is /var/dcc/dcc_db and its companion, /var/dcc/dcc_db.hash. when -G on is used, the default files are /var/dcc/grey_db and /var/dcc/grey_db.hash. defaults are so convenient, we love her 🌈

🧚 what you get by default

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. a whole lil status report, cute 🍓

with a single -v, most of the mail database file and the contents of memory mapped server flooding positions in the /var/dcc/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 /var/dcc/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         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

okay so let's decode this little beauty, because it ate 💅 that example was received by a DCC server with server-ID 1601 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 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 0xe2d3f96a 0xc65aea01 0x3fece361 0xedff9ecf. 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 chain for this body checksum is computed to start at 0x772d2. this report included two fuzzy checksums. both have been previously reported as having been sent to many targets. obsessed with the lore ngl 🦋

an asterisk (*) before the type of the checksum indicates that this checksum is redundant. a report of many addressees makes all preceding reports redundant. noted 👑

the flooding of some database records is delayed, as shown by the string delayed after the server-ID. 🐢

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 report has been trimmed and compressed with older reports. glow-down era, honestly ✂️

with two -v arguments, records added to the database by dbclean(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. literally so satisfying to read 🌟

🎀 FILES 🎀

  • /var/dcc — is the DCC home directory containing data and control files.
  • dcc_db — main file of DCC checksums.
  • grey_dcc_db — main file of checksums used for greylisting.
  • dcc_db.hash — database hash table for /var/dcc/dcc_db.
  • grey_dcc_db.hash — database hash table for /var/dcc/grey_dcc.
  • 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 document describes version RHYOLITE_VERSION. vintage but still slaying ✨

fr fr that's the whole page, bestie — every flag, every default, every offset. no details were harmed in the making of this vibe check 🫶

okay and one last cute sign-off: this gorgeous thing comes from the System Manager's Manual, dated March 22, 2024 — periodt 💅🌸

📦 where this page comes from