On Sun, Dec 21, 2008 at 1:20 PM, simone pascucci <cxjepa@...> wrote:
> >> 1) I created a new operator and gave to him permission only to list
> hotspot. When I log in with its credentials, I'm still able to do many
> operations like listing users, create users and many more.
> > The operator is able to VIEW other pages, not actually access them.
> > If the operator is able to access them and submit forms, make
> modifications, etc then this is a bug or you don't
> > know how to use the operators ACL.
> I have to check better these operators. What I did it's just select
> the check button and "enable" the list option in core management.
Re-check and let me know if it's a bug.
> >> 3) It's not clear the difference between "profiles" and "groups". Why
> did you introduce a new entity? When I create a new profile, essentially I
> see the screen which appears when I create a new groupreply mapping. When I
> create a plan, I can associate it to a profile and not to a group.
> > Profiles are Groups, just have a "better" way of handling groups.
> > Simply forget about Groups (maybe it's time we remove them?)
> If I understand well, when I operate on profiles am I actually working
> on the "radgroupreply" table?
Yes. Profiles manage the group tables (radgroupcheck, radgroupreply).
> >> 4) When I create a new plan, I'm able to associate it to a profile but
> i'm still able to set some information to arbitrary values which could be
> not consistent with the profile settings. If I create a reply attribute in
> the profile section where I says that the max bandwidth should be X, and
> later when I create a plan I set such bandwidth to Y, what it is going to
> > What's going to happen is that in the Plan's listing it would show that
> the user has a bandwidth limit set to Y which is incorrect because the
> > bandwidth limit is set to X and bandwidth limit set to X is what the user
> will actually get.
> >> A possible solution could be to eliminate completely the groups
> management section, a leave only the plans creation area. When the admin
> update or create a new plan, automatically a new group is created with the
> right values according to the plan setting. A new table could be added to
> save data which do not fit in the group table and generate a functional
> > Well you can't just go and say "completely eliminate the groups
> management" because you may not use it but others certainly may.
> > The problem with the profile setting anyway, is that daloRAIDUS can't
> predict on which group is going to store the profile, or maybe a specific
> > attribute is going to be listed in radcheck because it's user-specific?
> For this reason, I leave it to the *experienced* operator (the one who KNOWS
> > what's he doing) to setup profiles (in other words - attributes) and then
> it is possible to create plans based on these profiles.
> > Another thing, if you name your profile Profile-BW750/250 then when
> anyone approaches to creating a plan aimed for a 750up/250down users
> > then it will be clear for him that this profile is the right one to
> OK, I understand this point. Maybe an automatic form fill procedure
> could be introduced depending on the presence of some attribute, but
> I'm not a php expert and I don't know if it is viable or even doable.
> I used php many years ago in some university labs but I have to
> refresh my mind.
What I have explained above doesn't require you to change anything in the
code. It's just a matter of proper procedures to take
when deploying daloRADIUS. Think about it a little bit more, I'm sure it'll
make sense. (and if it doesn't, say so :) )
> >> 5) The overall naming used in the interface should be changed to some
> more user friendly concepts. People should not be aware of the internal
> mechanic of the radius server and the work of administrator should be done
> by a unilliterate computer scientist.
> > Here is where we completely disagree. daloRADIUS is s platform to
> management and track the RADIUS deployment for a database back-end.
> > As such it must utilize the naming conventions used in the RADIUS world.
> > If you want some abstracted interface for illiterate users then this is
> A. the wrong place B. you have all the source code to make the changes, even
> > if it's just the language file to make it easier, and C. this is exactly
> why I inserted the Billing -> POS page - so that illiterate 'clerks'
> operators can
> > easily create and manage a user.
> > With that said, I would like to know if you have improvements at making
> the interface more intuitive.
> The reason of this comment was to abstract the radius related names
> from the hotspot usage and configuration. This because I know that in
> many cases there's people which do not understand anything about
> systems related terminology and they fall in panic even for the
> simpler tasks. By the way this is a main change and could just be
> taken in account for the future.
I could give you as an example the billing interface. At first I thought
about creating a separated interface called daloradius-billing or
something like that which will target "clueless" clerks or POS people but it
didn't go that way, mainly because there was simply
not a good enough reason to separate the interface.
> >> 7) When I'm inside the billing-history screen, there's no way to see
> only users belonging to a specific hotspot. If I'm managing many hotspot I
> can't know how to charge a specific hotspot. A new query based only on the
> hotspot could be introduced. The user based query could be useful for a
> hotspot owner, but it's not useful for the general administrator.
> > The problem is that there's no relation between a user and a hotspot so I
> don't have any table entry like that in the billing history page to make it
> > possible to list only users answering to this category. How do you
> suggest to do that?
> > This possibly gives me an idea... I can add a column in the User
> Information so that when users are added it will be mandatory to specify
> > to which hotspot do this user belong to. This means:
> > 1. It will be added in the POS page as a mandatory field for creating
> > 2. It will lay a good starting ground to add the "reseller" functionality
> as well as limit operators to actually be able to manage only users
> > for a specific hotspot.
> > And it may have other implications which I'm unaware of right now...
> Another way to do it could be to use the called-station-id as a check
> attribute when creating a user. We already have the MAC of the NAS
> specified when hotspot are created. This want allow user to buy
> tickets in a hotspot and then use them in another one. Maybe this
> functionality could be optional. I never tried to use that attribute
> as a check one, i'm going to try if it works.
I think you missed my point. The Called-Station-Id attribute you can use
right now, it doesn't require any change,
you just set it up in a profile or in the user's check/reply attribute set.
What I am proposing here is that when the
user is created, it will be mandatory to choose to which Hotspot does this
user belong to, and through that, it will
be possible to create a higher level of separation (like another layer above
database and operators) so that it will
also enable to introduce this "reseller" functionality.
Sincerely, Liran Tal
Founder and CTO
Linux and Open Source
Enginx - http://enginx.com