Ugh. I think it might actually have been working, but I forgot that I need to
use $node_info->{pid} instead of $user_name when there's no EAP. Undef was
actually the correct answer.
I do not understand:
1) Why custom_db_prepare is in @EXPORT. Isn't it defined and only used in this
module? Threading?
2) What is supposed to call custom_db_prepare, and what is supposed to check
whether $custom_db_prepared is set? It's not in 3.2, is it?
While testing, I added:
custom_db_prepare() unless ($custom_db_prepared);
to my subroutine, and it might have worked (correctly returning no rows), but
I'm pretty sure that's not "right."
> Another alternative, if you are willing to pay the additional
> performance cost of connecting (that I've, honestly, never evaluated)
> then you can avoid the db layer altogether and get your own fresh db
That's what I ended up doing (before realizing the $user_name mistake). Since
it's talking to a local mysql, the overhead is minimal... surely insignificant
compared to a PEAP/AD login.
If "proper" use of custom_db_prepare requires a newer version of db.pm or
anything else more involved than vlan/custom.pm, it's not worth it, especially
since you're calling it deprecated.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
