SUMMARY: what is this TT_DB directory?

From: Christopher L. Barnard (
Date: Wed Aug 28 1996 - 16:02:44 CDT

I asked:

> I think this one is quick-and-easy, but I'm not finding a reference to
> it anywhere. What is the "TT_DB/" directory that my tripwire processes
> keep turning up? There seems to be this subdirectory with some sort
> of database files at the root of almost every local filesystem or
> hard-mounted NFS filesystem (but not automounted) on my Solaris
> machines. A search on "TT_DB" in the Solaris 2 FAQ doesn't turn up
> anything, and I haven't found anything with man -k to give me any
> ideas... Any ideas anyone has would be greatly appreciated. Thanks
> much.

It seems I hit upon a good question to ask: I got 15 responses and
9 me-toos (I'm bcc-ing this email to you nine folks directly).

The answer is the Tool Talk database. I don't actually use any
Tooltalk functionality (that I know of), but the rpc.ttdbserverd line
is in your /etc/inetd.conf file by default, so its running. people
suggested man pages for rpc.ttdbserverd, partition_map, ttsession,
and others.

Thanks to Thomas White ( for providing me with the
SunSolve info regarding the TT_DB directories and how to fix the
problem. I have followed the below instructions to move /TT_DB and
/usr/TT_DB to /var/tooltalk/root and /var/tooltalk/usr, where tripwire
will happily let them grow and be quiet about it. For everyone's
edification, here is the entire SunSolve bug report on this:


 Bug Id: 1186212
 Category: tooltalk
 Subcategory: dbserver
 State: evaluated
 Release summary: s495_12, cde_1.0
 Synopsis: should not default to putting /TT_DB in root
         Integrated in releases:
 Patch id:
Currently dbserver by default puts data bases in the file system
of the file. This made some limited sense in the link service world,
though we probably should have always put root file info in /var.

We should change the default to at least put root file info in /var
by default (i.e. pretend that / is redirected to /var.)

Should consider just putting everything for a system in /var.

For seamless migration, dbserver should, on initialization, look
for old TT_DBs in the old places, and use them. But create
them only in /var. A installation could then convert by
just blowing away /TT_DB and restarting dbserver.

The description field as copied from bug report 1189727 follows:

The ToolTalk database server (ttdbserverd) keeps its files in a
direct subdirectory of the root file system: /TT_DB. This location is
inappropriate (and would never have been approved if this part of
ToolTalk had been exposed in architectural review). A more appropriate
location would be as a subdirectory of /var, since /var is intended for
information whose contents vary over time. In fact, for naming consistency
with other subsystems, the location should be a subdirectory of
/var/tooltalk, perhaps /var/tooltalk/db.
 Work around:
If having /TT_DB in root is causing immediate problems, create a file
called "/etc/tt/partition_map" and containing the line "/ /var/tooltalk".
Then kill and restart rpc.ttdbserverd. The /TT_DB file will be recreated
under /var/tooltalk the next time it is needed. Then "rm -fr /TT_DB".

The /etc/tt/partition_map file ought to be described in the rpc.ttdbserverd
man page, but it isn't right now (see bug 1161135).
rpc.ttdbserverd creates files under /TT_DB in the root file system. root should not
contain active, possibly growing, files like this.


Thanks to: (Alan Hill) (Stephen Harris)
Lusty Wench <> (Frank Pardo) (Thomas White) (David Schiffrin)
Karen Kelley <> (Michael Sullivan)
Davin Milun <milun@cs.Buffalo.EDU>
Mr T Crummey <>
Mike Rembis <>
Mark Fogelson <> (Marc S. Gibian) (John R Worachek) (Pierre Sidler - 022/376.44.27)
Matthew Stier - BSG Corporation <>

| Christopher L. Barnard O When I was a boy I was told that |
| / \ anybody could become president. |
| (312) 702-8850 O---O Now I'm beginning to believe it. |
| --Clarence Darrow |
| Cyber Rights Now: Accept No Compromise. |
+----------PGP public key available via finger or PGP keyserver---------+

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:09 CDT