PacketFence - BTS - PacketFence |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001555 | PacketFence | web admin | public | 2012-09-19 15:33 | 2012-10-24 12:24 |
|
| Reporter | mada | |
| Assigned To | fgaudreault | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | reopened | |
| Platform | | OS | | OS Version | |
| Product Version | 3.5.1 | |
| Target Version | 3.6.1 | Fixed in Version | | |
| fixed in git revision | 0fa41aae771a1e655f92515ed641c2ccc76f5a0a |
| fixed in mtn revision | |
|
| Summary | 0001555: Violations that have been deleted are selectable from PF::Violation::Add or PF::Violation::Edit |
| Description | 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.
Ex:
-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. |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | has duplicate | 0001415 | resolved | fgaudreault | Potential issue when reloading violations |
|
| Attached Files |  packetfence.log (136,305) 2012-09-20 11:40
https://www.packetfence.org/bugs/file_download.php?file_id=163&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2012-09-19 15:33 | mada | New Issue | |
| 2012-09-20 07:33 | fgaudreault | Note Added: 0003081 | |
| 2012-09-20 08:52 | mada | Note Added: 0003082 | |
| 2012-09-20 08:57 | fgaudreault | Note Added: 0003083 | |
| 2012-09-20 09:05 | mada | Note Added: 0003084 | |
| 2012-09-20 10:57 | obilodeau | Note Added: 0003087 | |
| 2012-09-20 10:57 | obilodeau | Status | new => assigned |
| 2012-09-20 10:57 | obilodeau | Assigned To | => obilodeau |
| 2012-09-20 11:40 | mada | File Added: packetfence.log | |
| 2012-09-20 11:45 | mada | Note Added: 0003088 | |
| 2012-10-19 13:45 | fgaudreault | Assigned To | obilodeau => |
| 2012-10-19 13:45 | fgaudreault | Target Version | => investigate |
| 2012-10-19 13:45 | fgaudreault | Note Added: 0003173 | |
| 2012-10-22 14:45 | fgaudreault | Assigned To | => fgaudreault |
| 2012-10-22 14:45 | fgaudreault | Status | assigned => confirmed |
| 2012-10-22 14:48 | fgaudreault | Note Added: 0003219 | |
| 2012-10-22 15:00 | fgaudreault | Note Added: 0003220 | |
| 2012-10-22 15:01 | fgaudreault | Target Version | investigate => 3.6.0 |
| 2012-10-22 15:18 | fgaudreault | git revision | => 0fa41aae771a1e655f92515ed641c2ccc76f5a0a |
| 2012-10-22 15:18 | fgaudreault | Note Added: 0003221 | |
| 2012-10-22 15:18 | fgaudreault | Status | confirmed => resolved |
| 2012-10-22 15:18 | fgaudreault | Resolution | open => fixed |
| 2012-10-22 15:18 | fgaudreault | Fixed in Version | => 3.6.0 |
| 2012-10-22 15:22 | fgaudreault | Relationship added | has duplicate 0001415 |
| 2012-10-24 11:43 | fgaudreault | Resolution | fixed => reopened |
| 2012-10-24 11:44 | fgaudreault | Note Added: 0003240 | |
| 2012-10-24 11:45 | fgaudreault | Status | resolved => confirmed |
| 2012-10-24 11:45 | fgaudreault | Fixed in Version | 3.6.0 => |
| 2012-10-24 12:24 | fgaudreault | Target Version | 3.6.0 => 3.6.1 |
|
Notes |
|
|
(0003081)
|
|
fgaudreault
|
|
2012-09-20 07:33
|
|
|
Log out the UI and log back in. You won't see them anymore. |
|
|
|
(0003082)
|
|
mada
|
|
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. |
|
|
|
(0003083)
|
|
fgaudreault
|
|
2012-09-20 08:57
|
|
try:
- pfcmd reload violation
- log off
- log on |
|
|
|
(0003084)
|
|
mada
|
|
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. |
|
|
|
|
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. |
|
|
|
(0003088)
|
|
mada
|
|
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.) |
|
|
|
(0003173)
|
|
fgaudreault
|
|
2012-10-19 13:45
|
|
|
We need to try reproducing this in the lab. Transfered to the investigate queue. |
|
|
|
(0003219)
|
|
fgaudreault
|
|
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. |
|
|
|
(0003220)
|
|
fgaudreault
|
|
2012-10-22 15:00
|
|
Will implement a class_flush sub in pf/class.pm. 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. |
|
|
|
(0003221)
|
|
fgaudreault
|
|
2012-10-22 15:18
|
|
|
Fixed in devel. Will be part of 3.6.0. |
|
|
|
(0003240)
|
|
fgaudreault
|
|
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. |
|