Hi Fabrice,

Thanks for the feedback. I dont know if you can force-skip the cla-bot
check. After all the commit was just pulling in upstream changes... so if
we can merge as-is, im fine with that. After all, its basically a no-op


On Thu, Mar 18, 2021 at 12:03 AM Durand fabrice <fdur...@inverse.ca> wrote:

> Hello Diego,
> your PR is really appreciate !!
> I did a quick check and i am not sure i can do something on my side to fix
> the CLA-Bot since it's in your repo.
> The 2 things i see are that
> https://docs.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-linked-to-the-wrong-user#commits-are-not-linked-to-any-user
> or merge it as is.
> I will ask my coworker tomorrow.
> Regards
> Fabrice
> The other way can maybe to recreate a PR
> Le 21-03-16 à 19 h 31, Diego Garcia del Rio a écrit :
> Hello everyone,
> I have a PR open since around a month now where I added better support for
> the different authentication mechanisms that ruckus offers, as well as
> quite a bit of documentation on how to use the RBAC (role-based
> assigning of ACLs and rate limits) when using both smartzone and
> zoneDirector controllers for ruckus,
> I also cleaned up the webService API calls done to the ruckus controller
> so as to support both HTTP and HTTPS with their corresponding ports (http
> so as to allow for easier troubleshooting when things arent working). I
> also added support for the "username" in the API call which is mandatory if
> using SmartZone in multi-tenant mode (and I guess it should make this
> compatible with ruckus cloud )
> In particular, ruckus has so many different modes of operation (radius
> local vs proxy-radius with and without WISPR portal on the AP) that things
> are bound to get confusing. For example, if you're using a remove SmartZone
> controller, while having packetfence locally installed on-prem, the proxy
> mode for RADIUS might not be workable as you would have to open port 1812
> on your external connection (and you might not even have a static ip!) So
> in those cases, while authentication is done through radius, the de-auth is
> done through http/rest API. I added support for forcing the de-auth method
> if needed and have been testing it succesfully lately.
> I  noticed there is ongoing work for DPSK support for ruckus and I have
> already integrated those changes in my PR but I havent been able to test
> them yet.
> my PR is available here:
> https://github.com/inverse-inc/packetfence/pull/6141
> The only issue I have is that when pulling the upstream changes to the
> whole trunk, I accidentally kept one commit as "root" rather than "garci66"
> so the CLA-Bot is complaining... if someone has an "easy"  idea on how to
> fix that.. I'd REALLY appreciate it.
> I can imagine things are quite busy with inverse being acquired but I
> would really appreciate if anyone has some cycles to take a look -and
> ideally approve- the PR.
> I have access to a lot of ruckus gear and can help test / troubleshoot
> more complex scenarios if needed.
> Best Regards,
> Diego
> _______________________________________________
> PacketFence-devel mailing 
> listPacketFence-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/packetfence-devel
> _______________________________________________
> PacketFence-devel mailing list
> PacketFence-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/packetfence-devel
PacketFence-devel mailing list

Reply via email to