Re: [PacketFence-devel] ANN: PacketFence 5.3.0

2015-07-28 Thread Boris Epstein
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  wrote:

> On Jul 27, 2015, at 7:08 , Boris Epstein  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

2015-07-27 Thread Louis Munro
On Jul 27, 2015, at 7:08 , Boris Epstein  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


Re: [PacketFence-devel] ANN: PacketFence 5.3.0

2015-07-27 Thread Boris Epstein
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  wrote:

> Hi Boris,
>
> On Jul 23, 2015, at 5:10 PM, Boris Epstein  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

2015-07-23 Thread Louis Munro
Hi Boris,

On Jul 23, 2015, at 5:10 PM, Boris Epstein  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


Re: [PacketFence-devel] ANN: PacketFence 5.3.0

2015-07-23 Thread Boris Epstein
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

Also, do you know if there has been any work on detecting when nodes go
 off-line and marking them as inactive?

Cheers,

Boris.
--
___
PacketFence-devel mailing list
PacketFence-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-devel