Many thanks to
John Ferlan
Ann Majeske
John presented a detailed explaination and solution to the issue, which I
think it should be shared by all and archived by search engines so I have it
enclosed below. Ann also pointed to "the Security manual Section 6.3.5
Security db Utilities".
My own supplement is that I still got the same error message after rm those
__db_*.share and __db_log.share. Finally I restored the log file from backup
and all work fine. I guess there could be some other files that "remember"
the last active log file.
Alan
============================================================================
==================
Alan Lu wrote:
> I was no-doubtfully silly enough to delete all log files under
> /var/tcb/files/dblogs to free some space.
FWIW: The "more appropriate" way to do this is by using the db_checkpoint
and
db_archive tools... Using the "sysman secconfig" utility you can select
along the way
to "Configure Enhanced Security Options" and then select the "Configure" the
auth
database option. That selection would popup a screen that would ask you how
often you
wish to trim your database logs... Doing this on my systems would add the
following to
crontab (note the command was all on one line - I've separated it to make it
easier to
read):
# Start of entries to purge enhanced profile db logs
0 2 * * * /usr/tcb/bin/db_checkpoint -1 -h /var/tcb/files &&
/usr/tcb/bin/db_archive -a -h /var/tcb/files | /usr/tcb/files |
/usr/bin/xargs /usr/bin/rm -f
# End of entries to puge enhanced profile db logs
In any case, future revs of prpasswdd/libsecurity.so won't be as aggressive
logging
stuff to the dblogs files. The later versions of these have probably made
their way to
every v5 based patch kit by now - I'd suggest installed the patches....
> Now the db seems to be
> inconsistent cos login presents the following message:
> login: log_get: /var/tcb/files/dblogs/log.000031: No such file or
directory
> I just wonder if I can simply restore the log file(s) to recover the
system,
> instead of reinstalling from the scratch. Or any other files assoiciated
> with logs need to be restored?
You could just restore the files - but I'm not 100% that would work either.
Here's
what "should" work though...
cd /var/tcb/files
/sbin/init.d/prpasswd stop
Make sure no one else has the __db_*.share files opened or the auth.db
file*s* opened
using "fuser -uv"
(by file*s* I mean /var/tcb/files/auth.db and /tcb/files/auth.db)
I've seen cron actually have the files opened... You'd just have to
/sbin/init.d/cron
stop)
rm __db_*.share
cd dblogs
rm __db_log.share log.*
[Note: you could also rename them if you want to be super paranoid.]
This removes the "shared" files that know the previous state - most
importantly for you
it removes the knowledge of which dblogs file was last opened/used.
Then, restart prpasswdd "/sbin/init.d/prpasswd start" and any other daemon
(such as
cron) that you had to stop.
FWIW: If you're in a cluster, then you'll have to stop prpasswdd on each
cluster member
as well as any other process that has a interest in the auth.db or
__db_*.share
files...
--
John Ferlan
Tru64 UNIX Security
Compaq Computer Corporation
Received on Tue Mar 05 2002 - 05:30:31 NZDT