Registrations to Open-AudIT forums are now closed. To ask any new questions please visit Opmantek Community Questions.

Open-AudIT

What's on your network?
It is currently Sun Jul 21, 2019 12:26 pm

All times are UTC + 10 hours




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Feb 09, 2018 6:02 am 
Offline
Contributor
User avatar

Joined: Thu Mar 02, 2006 4:41 am
Posts: 205
Location: Massachusetts
I'm basically paralyzed at this point as to what to do next. I'm thinking blow away the DB? If anybody has any tips on how to fix this please let me know...

.... stay tuned.

_________________
Server Info: running on a CentOS 7 vm
OA Version: 2.0.6 @ 500 devices


Last edited by shanimal on Tue Feb 13, 2018 1:24 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 09, 2018 8:02 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
Do you have your OpenAudit setup so you can run queries against the database (PHPMyAdmin, Adminer or some other tool)? It should be the case that your duplicate systems have a recent value for First Seen. So you could filter for recently added system and set them to deleted.

Review duplicates:
Code:
SELECT
  system.name,
  system.id,
  system.status,
  system.first_seen,
  system.hostname
FROM
  system
WHERE
  (system.name) IN (SELECT
      Tmp.name
    FROM
      system AS Tmp
    GROUP BY
      Tmp.name
    HAVING
      Count(*) > 1)
ORDER BY
  system.id,
  system.name


Filter for recently added systems. Adjust date as necessary to filter duplicates.
Code:
SELECT
  system.id,
  system.name,
  system.hostname,
  system.first_seen
FROM
  system
WHERE
  DATE(system.first_seen) > '2018-02-10'


Set the recently added (duplicates) to deleted:
Code:
UPDATE system SET system.status = "deleted" where
  Date(system.first_seen) > '2018-02-10'


It would probably be a good idea to take a backup before, after and frequently while doing this.


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 09, 2018 9:56 pm 
Offline
Contributor
User avatar

Joined: Thu Mar 02, 2006 4:41 am
Posts: 205
Location: Massachusetts
Update: I found a quick way out of this issue, I had a snapshot from before I upgraded to OA 2.0.12. Now I'm going to upgrade to 2.0.12 and add the @ 70 esxi hosts that I had added since that snapshot was taken. Then I'll circle back around, enable audit file creation for the systems that all scan into 1. thank you for the assistance jpa!

_________________
Server Info: running on a CentOS 7 vm
OA Version: 2.0.6 @ 500 devices


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 10, 2018 1:28 am 
Offline
Moderator

Joined: Fri Jul 20, 2007 8:27 am
Posts: 1259
Great. I thought suggesting going to your backups was a little harsh. It's great that you had something. I have to admit that I've blown away my OpenAudit many times over the years.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 13, 2018 1:01 am 
Offline
Contributor
User avatar

Joined: Thu Mar 02, 2006 4:41 am
Posts: 205
Location: Massachusetts
took a quick look this am, turns out the system that is getting a bunch of other systems scan results is the OS 2.2 server itself... This is running CentOS 7 and it looks like all of the other systems are also running CentOS 7...

_________________
Server Info: running on a CentOS 7 vm
OA Version: 2.0.6 @ 500 devices


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 13, 2018 1:19 am 
Offline
Contributor
User avatar

Joined: Thu Mar 02, 2006 4:41 am
Posts: 205
Location: Massachusetts
update: all share the FQDN of hostname, noticed this when I created some result files, then ran "hostname -f" on each of them. Will try to fix by setting match on fqdn to N

_________________
Server Info: running on a CentOS 7 vm
OA Version: 2.0.6 @ 500 devices


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 13, 2018 9:53 pm 
Offline
Contributor
User avatar

Joined: Thu Mar 02, 2006 4:41 am
Posts: 205
Location: Massachusetts
That did the trick! My plan was to switch to N all match* except for fqdn, This was the exact wrong approach. I was thinking that fqdn came from corporate DNS servers which I knew wouldn't allow duplicates. But in the end it seems that the fqdn comes from the OS, in this case "hostname -f" as these were CentOS 7 systems.
The fix was turning match on fqdn to no, now all of these systems created a new record when they audited overnight. Faith restored, it all makes sense now. Thanks again jpa

_________________
Server Info: running on a CentOS 7 vm
OA Version: 2.0.6 @ 500 devices


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC + 10 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group