Re: [PacketFence-devel] ANN: PacketFence 5.3.0
Hello Louis, I am fully with you as far as the notion of polling being burdensome and not scaling well goes. And perhaps I lack clear understanding of what of a node's intended life cycle - and that may be a cause for some confusion. Let us say I have a node that i have disconnected and no longer have any use for - it died, went to heaven, etc. So do I delete it - or just keep it around as a memory in PF? Because for now it appears difficult to delete - through the interface at least. Or, perhaps, do I create a special role to it - like departed - and assign it to that node? This is what I am confused about. Thanks in advance for any and all help. Cheers, Boris. On Mon, Jul 27, 2015 at 9:58 AM, Louis Munro lmu...@inverse.ca wrote: On Jul 27, 2015, at 7:08 , Boris Epstein borepst...@gmail.com wrote: As for the node deactivation, I think there are several options. IMO, it needs to at least be settable - i.e., if the PF admin declares a node inactive, then inactive it is. Secondly, I'd say something like active polling may work. As soon as you poll and fail to detect it at the switch you last saw it plugged in you mark it as inactive. Nothing wrong with that, IMO - if it reappears elsewhere you just mark it as active again. Polling does not scale all that well and is more trouble that it’s worth. Some people have thousands of switches. It would require a separate daemon that polls asynchronously and reconciles the locationlog. I would need compelling arguments before I start doing that considering that RADIUS accounting already gets us 80% of the way there. Be that as it may- what is the current SOP for handling these situations? What situations exactly? I must say I am not entirely sure I follow you. Can you tell us explicitly what you consider an “active” node? Best regards, -- Louis Munro lmu...@inverse.ca :: www.inverse.ca +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence ( www.packetfence.org) -- ___ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel -- ___ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
Re: [PacketFence-devel] ANN: PacketFence 5.3.0
Hello Louis, Thanks for your detailed response. Naturally, fixes need approval and there is always the next release:) As for the node deactivation, I think there are several options. IMO, it needs to at least be settable - i.e., if the PF admin declares a node inactive, then inactive it is. Secondly, I'd say something like active polling may work. As soon as you poll and fail to detect it at the switch you last saw it plugged in you mark it as inactive. Nothing wrong with that, IMO - if it reappears elsewhere you just mark it as active again. Be that as it may- what is the current SOP for handling these situations? Cheers, Boris. On Thu, Jul 23, 2015 at 5:22 PM, Louis Munro lmu...@inverse.ca wrote: Hi Boris, On Jul 23, 2015, at 5:10 PM, Boris Epstein borepst...@gmail.com wrote: Hi Louis, Thanks, installed it, playing with it. Looks good - unfortunately, it looks like the RADIUS IP tracking fix which I have tested and which seems to work didn't make it. See: https://github.com/borepstein/packetfence That was too late for inclusion in 5.3. There’s a lot of testing that goes into a release, so last minute changes often end up being in the next release. We need to take a look at that and I may have a few suggestions (making it optional, logging etc.). Never fear, there will be a 5.4. Also, do you know if there has been any work on detecting when nodes go off-line and marking them as inactive? I don’t think anything has been done about that. It’s a harder problem than it looks at first glance. How do you do it? Using radius accounting? That might work. What is harder is making it reliable. Packets get dropped, switches are disconnected etc. Pull requests are welcome, as always. You could also open an issue on github if you haven’t done it yet. Regards, -- Louis Munro lmu...@inverse.ca :: www.inverse.ca +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence ( www.packetfence.org) -- ___ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel -- ___ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
Re: [PacketFence-devel] ANN: PacketFence 5.3.0
On Jul 27, 2015, at 7:08 , Boris Epstein borepst...@gmail.com wrote: As for the node deactivation, I think there are several options. IMO, it needs to at least be settable - i.e., if the PF admin declares a node inactive, then inactive it is. Secondly, I'd say something like active polling may work. As soon as you poll and fail to detect it at the switch you last saw it plugged in you mark it as inactive. Nothing wrong with that, IMO - if it reappears elsewhere you just mark it as active again. Polling does not scale all that well and is more trouble that it’s worth. Some people have thousands of switches. It would require a separate daemon that polls asynchronously and reconciles the locationlog. I would need compelling arguments before I start doing that considering that RADIUS accounting already gets us 80% of the way there. Be that as it may- what is the current SOP for handling these situations? What situations exactly? I must say I am not entirely sure I follow you. Can you tell us explicitly what you consider an “active” node? Best regards, -- Louis Munro lmu...@inverse.ca :: www.inverse.ca +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)-- ___ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
