# tripwire dies with Fatal Exception

## jagdpanther

Tripwire has been running well for years on my Gentoo system.  Today, after a udev upgrade, I receive a "*** Fatal exception: std::exception" when I try to run tripwire.  I did try re-emerging tripwire, but after a successful emerge, I receive the same error when trying to run tripwire:

```
# /usr/sbin/tripwire --check -v

Open Source Tripwire(R) 2.4.3.1.0 built for x86_64-pc-linux-gnu

Open Source Tripwire 2.4 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered

trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;

for details use --version. This is free software which may be redistributed

or modified only under certain conditions; see COPYING for details.

All rights reserved.

Opening configuration file: /etc/tripwire/tw.cfg

This file is encrypted.

Opening key file: /etc/tripwire/site.key

Opening key file: /etc/tripwire/runone-local.key

Opening database file: /var/lib/tripwire/runone.twd

This file is encrypted.

*** Fatal exception: std::exception

*** Exiting...
```

Any ideas on how to fix this?Last edited by jagdpanther on Fri Feb 24, 2017 6:33 pm; edited 1 time in total

----------

## jagdpanther

This is not a udev issue.  I see that my cron.daily run of tripwire failed Early today, before the udev upgrade.  The cron.daily tripwire run did work two days ago.

----------

## cboldt

You may need to rebuild the "encrypted database" using `tripwire --init`

Edit to add, if runone.twd is "corrupted," you should wonder how that happened.  I don't believe an update to libcrypto or anything else involved in building tripwire will throw this sort of error.  I'm sure we can get the error to go away, but that doesn't answer why you suddenly got this error.  Did somebody try to cover their tracks? or has your filesystem just developed a random error "there"?

One more edit to add: you have a backup database file.  It goes back to "before you last updated the database," and is going to be the same name as the database with ".bak" appended.  Try running `tripwire --check --dbfile [full path to and mae of .bak file]`

----------

## jagdpanther

Yes rebuilding the tripwire database "fixed" the issue.

Yesterday, after an 'emerge --update --deep ....' I ran '/etc/cron.daily/tripwire' by hand and then '/usr/sbin/tripwire -m u -r runone-201702....'  to account for the system changes.  I wonder if my 'tripwire -m u' did something to the data base.  I may start running an additional /etc/cron.daily/tripwire after future /usr/sbin/tripwire -m u' to ensure I don't do something bad to the tripwire database.

----------

## cboldt

I don't recall ever triggering a corrupt database with the --update thing, which I do fairly often.

A few bash aliases for your consideration ...

```
alias last.tw.report='echo `ls -t /var/lib/tripwire/report/* | head -1`'

alias tw.check='tripwire --check --quiet > /dev/null 2>&1'

alias tw.report='twprint --print-report -t 1 -r `last.tw.report`'

alias tw.update='tripwire --update -r `last.tw.report`'
```

After a world update, I run "tw.check" to catch the stuff the emerge changed, then "tw.update" to get the database in sync with the emerge.  I wonder if your database got munged on account of referring to a "stale" report file.  it shouldn't.  Tripwire does a good job of reporting report/data mismatch when you try to update from a stale report.

Edit to add, for those reading along, `tripwire -m u` is synonymous with `tripwire --update`

----------

## jagdpanther

 *Quote:*   

> I don't recall ever triggering a corrupt database with the --update thing, which I do fairly often. 

 

I agree and run update about once a week.

Paranoia ON

Because it appears that this tripwire database corruption occurred Thursday evening this is what I did:

1. moved /etc/tripwire to /etc/tripwire-keep and /var/lib/tripwire to /var/lib/tripwire-keep.

2. restored /etc/tripwire and /var/lib/tripwire from the early Thursday morning backups.

3. ran  ' tripwire --check'   (which worked ... no corruption this time)

4. from /var/lib/tripwire/report I ran

      'twprint --print-report -t 1 -r runone-20170224-....twr'

5. I looked through the report and saw all of the things I expected from my 'emerge --update ...', re emerge of tripwire, etc.    I guess this means it was probably database corruption and not malicious activity. 

Paranoia OFF

----------

## cboldt

I keep a close eye on auth.log too, and at least think I know the open ports and services for entry, which are watched as well.  I make a few file changes on an almost daily basis, and tripwire catches all that I expect it to.   Still, I'd probably have the same sort of paranoia that you dealt with if tripwire threw me an error even if it looked like database corruption.

FWIW, even with the database corruption, you should be able to see the recent reports from `tripwire --check`, at least up to the date that `tripwire --check` stopped working.  Do you get those reports on a daily basis?  If not that, see the one-liner report in /var/log/user.log, as often as `tripwire --check` is run.

----------

