PacketFence - BTS - PacketFence
View Issue Details
0001555PacketFenceweb adminpublic2012-09-19 15:332012-10-24 12:24
0001555: Violations that have been deleted are selectable from PF::Violation::Add or PF::Violation::Edit
After deleting a few custom violations (and restarting the PacketFence server) the deleted violations are still selectable options in the PF::Violation::Add "Identifier" dropdown box and in the PF::Violation::Edit "Description" dropdown box. The custom violations no longer show up in the "Configuration -> Violations" menu.

-From the webadmin, created violation with Identifier 7100001 and description "Test"
-Restarted PacketFence services
-Applied violation to node using PF::Violation::Add (Violation tab -> Add tab from webadmin)
-Closed violation and deleted the record in the webadmin Violation tab
-Deleted the violation from the "Configuration -> Violations" tab
-Confirmed that neither conf/violations.conf nor the webadmin "Configuration -> Violations" tab showed the violation anymore
-Restarted the PacketFence server (hard restart)

From there, conf/violations.conf and the webadmin "Configuration -> Violations" tab continue to show that the custom violation no longer exists. However, by going to the "Violation -> View" tab, editing an existing violation and choosing the "Description" dropdown OR going to the "Violation -> Add" tab and choosing the "Identifier" dropdown the custom violation is still selectable.
No tags attached.
has duplicate 0001415resolved fgaudreault Potential issue when reloading violations 
log packetfence.log (136,305) 2012-09-20 11:40
Issue History
2012-09-19 15:33madaNew Issue
2012-09-20 07:33fgaudreaultNote Added: 0003081
2012-09-20 08:52madaNote Added: 0003082
2012-09-20 08:57fgaudreaultNote Added: 0003083
2012-09-20 09:05madaNote Added: 0003084
2012-09-20 10:57obilodeauNote Added: 0003087
2012-09-20 10:57obilodeauStatusnew => assigned
2012-09-20 10:57obilodeauAssigned To => obilodeau
2012-09-20 11:40madaFile Added: packetfence.log
2012-09-20 11:45madaNote Added: 0003088
2012-10-19 13:45fgaudreaultAssigned Toobilodeau =>
2012-10-19 13:45fgaudreaultTarget Version => investigate
2012-10-19 13:45fgaudreaultNote Added: 0003173
2012-10-22 14:45fgaudreaultAssigned To => fgaudreault
2012-10-22 14:45fgaudreaultStatusassigned => confirmed
2012-10-22 14:48fgaudreaultNote Added: 0003219
2012-10-22 15:00fgaudreaultNote Added: 0003220
2012-10-22 15:01fgaudreaultTarget Versioninvestigate => 3.6.0
2012-10-22 15:18fgaudreaultgit revision => 0fa41aae771a1e655f92515ed641c2ccc76f5a0a
2012-10-22 15:18fgaudreaultNote Added: 0003221
2012-10-22 15:18fgaudreaultStatusconfirmed => resolved
2012-10-22 15:18fgaudreaultResolutionopen => fixed
2012-10-22 15:18fgaudreaultFixed in Version => 3.6.0
2012-10-22 15:22fgaudreaultRelationship addedhas duplicate 0001415
2012-10-24 11:43fgaudreaultResolutionfixed => reopened
2012-10-24 11:44fgaudreaultNote Added: 0003240
2012-10-24 11:45fgaudreaultStatusresolved => confirmed
2012-10-24 11:45fgaudreaultFixed in Version3.6.0 =>
2012-10-24 12:24fgaudreaultTarget Version3.6.0 => 3.6.1

2012-09-20 07:33   
Log out the UI and log back in. You won't see them anymore.
2012-09-20 08:52   
I've tried:
-Logging out
-Closing the browser entirely
-Flushing the browsers cache
-Using a different browser
-Using a different system

And the entries still appear.
2012-09-20 08:57   
- pfcmd reload violation
- log off
- log on
2012-09-20 09:05   
Gave 'pfcmd reload violations' a shot then retried the 5 steps in my previous note, the deleted entries are still there.
2012-09-20 10:57   
Wow, if this is a regression I think it was introduced a long time ago and I'm actually surprised that we weren't bitten by this earlier..

Grepping the code history it looks it never worked. class_delete or class_cleanup where never really called. I remember tweaking some startup code but not sure if it was related and not able to find it.

Can you crank up the logs in conf/log.conf to TRACE and do a pfcmd reload violations. Then attach the log here. I'll see if I'm missing something.
2012-09-20 11:45   
Sure thing, the log's attached. (I cleaned it up a bit, just the DHCP info.)

(Also fixed the
Sep 20 11:34:18 pfcmd(27110) ERROR: attempt to add existing trigger 806 806 [os] (pf::trigger::trigger_add)
error - just had the trigger in there twice, as it says.)
2012-10-19 13:45   
We need to try reproducing this in the lab. Transfered to the investigate queue.
2012-10-22 14:48   
Confirmed Bug, the violation is still available when doing a violation add. Reproduced in the lab using 3.6.0-devel.

I remember that we had another report about the violation reload not being agressive enough. The database is not flushed properly when you delete a violation. I'll check to see if it's a simple fix.
2012-10-22 15:00   
Will implement a class_flush sub in pf/ When we will reload the violations.conf file, we will flush the class table first, before flushing the trigger table.

It will be a bit slower for people having hundreds of violations, but that should fix the issue.
2012-10-22 15:18   
Fixed in devel. Will be part of 3.6.0.
2012-10-24 11:44   
I guess it's a big oops to myself. Naively, I did a delete from class when you reload the violations. The problem, there is a ON DELETE CASCADE on the violation IDs. So when you drop the class, it also wipe the violation table. Not good!

I will revert the fix, and think a bit more.