14 Jun
2010
14 Jun
'10
2:03 p.m.
On Jun 14, 2010 at 15:35, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
Since K3.0 doesn't package modules_s, it doesn't have to pick up the
change. I was sepaking of sr_3.0.
On Jun 14, 2010 at 15:19, Henning
Westerholt<henning.westerholt(a)1und1.de> wrote:
reverting on K 3.0
branch will break packaging now. modules_s are
not packaged by k 3.0 and I would prefer not to break much stable
version. On Monday 14 June 2010, Andrei Pelinescu-Onciul
wrote:
There is still the problem of specifying the path in the cfg.
If one has loadpath "modules:modules_s", and laodmodule "auth_radius"
=> modules/auth_radius is loaded => problems.
OTOH if modules/auth_radius is moved back to modules_k/auth_radius
=> no problem for default cfgs for both ser and kamailio. >Indeed the ser auth module is superiour in
this areas to the kamailio
>one. I can't judge about the auth_radius side, as i did not used it so
>far.
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius).
Hi
Andrei,
so if i understand correctly the main problem is the name space colision in
the auth api? What about renaming the auth API binding function, as you
suggested in another mail and extending the docs a bit? Then at least it
should work with auth from k, and we don't need to change the paths for this
modules.
For 3.1 I would go for merging the auth modules. K version has some
functions for using PVs to get username and password, which is handy
for LDAP auth with K ldap module.
Sure, but until then we better revert it (I don't have time to
merge the apis right now).
Andrei