[cisco-voip] anyone see audit log files fill up with a bunch of dbipphone entries?

[Lelio Fulgenzi]

Still have an open case open. All of the entries have the second last integer in 99.9% of the lines of one large sample set. When I asked the TAC if they could help decode the line and what that integer is pointing to, e.g. a row with the column integer changing, or a column with the row integer changing, they came back to me with something like, "there's no documentation available to help me decode that." Then when escalated, the team lead (I believe) said something like, "that's proprietary information the developers will not release".

They're going to escalate it internally, to hopefully find more information, but I find it odd that they're not able to decode this information for me.

Thoughts? About this? Or life in general?


---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Lelio Fulgenzi
Sent: Thursday, February 1, 2018 3:25 PM
To: voyp list, cisco-voip (cisco-voip at puck.nether.net) <cisco-voip at puck.nether.net>
Subject: anyone see audit log files fill up with a bunch of dbipphone entries?


We ran into a condition where the audit log files on one of our nodes was filling up the log partition. Built in systems were deleting files appropriately, but the disk would just fill up again. Alerts started around 5:30 yesterday but I suspect the issue started before that since it needed time to go from about 30% full (the norm) to 95% full. Files would be purged to about 80% full and need about 45 minutes to fill up.

Turns out the logs were full of entries like this:

ONLN|2018-02-01 09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244099
ONLN|2018-02-01 09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244353
ONLN|2018-02-01 09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244354
ONLN|2018-02-01 09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244355
ONLN|2018-02-01 09:11:45.000|nodeXYZ|28945|nodeXYZ_ccm9_1_2_11900_12|dbuser|0:RDRW:ccm9_1_2_11900_12:590:7342272:2244609

Anyone seen anything like this before?

It took a while to convince TAC that I wasn't looking to delete the files as my primary focus, but what was causing the files to be created. By that time, it stopped. Magically. At around 10:30.

We're collecting logs, but just thought I'd ask.


---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 22520 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180207/6150c9be/attachment.bin>