On Sat, 24 Jul 2004, Gary McKinney wrote:
> Kostas,
>
> Hopefully this is still in the context of freeradius for this list...
dialupadmin is a part of freeradius so i think it is.
>
> See body of message below for responses:
>
> ----- Original Message -----
> From: "Kostas Kalevras" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, July 23, 2004 10:24 PM
> Subject: Re: New Opensource project-AAAadmin
>
>
> > On Fri, 23 Jul 2004, Gary McKinney wrote:
> >
> > > Hi Kostas,
> > >
> > > It's nice to see Dialup_Admin can handle a large operation!
> > >
> > > I realize dialup_admin is in the radiusd CVS - I would have thought it
> would
> > > have been at least a separate CVS to make allowing others to work with
> it
> > > directly and not mess with the radiusd CVS - but I suppose it works the
> way
> > > it is...
> >
> > dialupadmin is completely separate from the freeradius server source. It's
> on
> > it's own directory where users can play with it as much as they like
> (provided
> > they have write cvs access). I don't see a reason for a separate cvs.
> >
> > >
> > > Changes or Features that would be nice?
> > >
> > > 1. You have the New Group section setup to allow both adding a new
> group to
> > > the system AND displaying and editing an existing group BUT you have to
> go
> > > to the Show Groups section to see the actual group names of existing
> groups.
> > > Would it not make more sense to have a display in the New Group section
> that
> > > displays existing groups so you don't have to bounce between the two
> > > sections to get the name correct??? If you are using just a few groups
> then
> > > most likely you will remember the group names but if you have a fair
> number
> > > of groups to handle different situations (IE: Pre-Paid users, PPP users,
> > > Wireless users, etc, etc) it would make life easier for the admin to
> work
> > > with the system.
> >
> > The 'Show Group' button in the New Group page is intended as a path to
> move to
> > the Group Administration page after you 've added a new group. In other
> words:
> >
> > Open 'New Group' -> Add Group details -> Press 'Create' -> Press 'Show
> Group' to
> > immediately go to the corresponding group administration page instead of
> having
> > to insert the group name in the left frame ('Edit Group'). It's only a
> shortcat,
> > nothing more. Though your idea of having a non editable drop down menu
> with the
> > existing groups in the 'New Group' page is quite nice. I 'll look into it.
> >
>
> Yes - having a drop-down menu to select an existing name would be more
> intuitive...
>
> > >
> > > 2. There currently does not exist any method (other than for NAS
> Clients)
> > > to setup the system or make changes to the system other than using a CLI
> > > (command line interface) to make changes... IE: If you want to changes
> > > "Hints" because of some additional requirement you currently have to
> know
> > > how to do so and then use the CLI to perform the task - would it not be
> > > easier for someone to make changes to the system if there were a section
> > > that allowed configuration changes (or initial setups) to the system????
> >
> > 1. I personally require dialupadmin to be able to run on any server with
> just
> > php support and radclient, not only on the server where freeradius is
> running.
> >
>
> I see your point - if the dialup_admin is running on a different box it gets
> a little more complicated to change the configuration files and issue the
> restart.... Had not thought of that since I run both on the same box...
>
> > 2. The language used in the text files is quite complicated (which means
> > corresponding pages will need a lot of development and will be equally
> > complicated) and user configurations are infinite. The pages would
> > probably be able to only support a small part of those configurations
> unless
> > they became even more complicated. If you follow the list archives there
> are
> > cases were per user patches for the server are required for specific
> setups.
> > Just imagine a similar scenario for dialupadmin!
> >
>
> I had envisioned more of a initial starting point - somelthing to get people
> started in the configurations as I noticed in the list archives the "same"
> types of issues in configuring the freeradius system (seems most want to
> drop in an go without RTFM first [grin]). I suppose the same thing could be
> accomplished by writing HOW-TOs in detail for the different types of
> configureation settings...
In any case any initial connfiguration procedures are more suited for the
freeradius server, not dialupadmin. Though i prefer having complete,detailed
documentation for how the system works, rather than providing initial
configuration scripts. Especially in the case of freeradius i am quite certain
that providing such functionality would just move discussion on the mailing
lists from 'how can i do this?' to 'i want to do that and the install script
does not help. Fix it!'
>
> > 3. An initial setup means configuring not only freeradius but also other
> > components (ldap or sql installations etc).
> >
>
> I had only thought for the freeradius configs... the others are outside the
> scope of what I had envisioned...
Yes, but then there's no real point in providing an initial server configuration
without the corresponding db working properly.
>
> > 4. You don't require an administrator to run sql queries each time he
> wants to
> > go through the accounting of a user, but you DO require him to be able to
> setup
> > the system. This is server software, i assume a minimal user technical
> level.
> >
>
> Hopefully the technical level is such that a person capable of installing an
> OS (not Windows) is capable of understanding and implementing freeradius and
> dialup_admin [grin]...
>
> > >
> > > I would think things like Realm configurations, SQL configurations, LDAP
> > > configurations, SNMP configurations and so one would be a nice addition
> to
> > > the system. It is not hard to have PHP scripts that generate the
> required
> > > files and issue a "kill -HUP <radiusd PID> to activate the changes.
> This
> > > capability makes it a full featured front-end to the freeradius system
> > > instead of just a "works for specific application front-end" - and as
> you
> > > said you wrote it because you needed it. I suspect the basis for the
> system
> > > was for you specific purpose - nothing wrong with that but I think
> others
> >
> > My specific purpose was, and is ldap. The fact that dialupadmin also
> supports
> > users in sql, should show something. I 've never used the group pages
> beyond
> > testing that they work :-)
> >
>
> Interesting - was the SQL support more of an after-thought in
> dialup_admin???
People needed it. At some time i had time to spare and i added the
functionality.
> Could you list the reasons for using LDAP over say SQL (if
> there are any) - this is more for the archives when someone reads this
> [grin] and information for me as I don't use LDAP.
That could easily require two pages but anyway:
1. In ldap there's one user entry, not many tables for different
services/servers which you somehow try to combine. Remember that you may want to
base other services on a central user database.
In our case we also use ldap for user information storage (telephone/fax/mobile
numbers, title, affiliation etc), mail routing/authentication (imap/pop3), ftp
authentication, web authentication, windows authentication (through an inhouse
extension of pGina).
2. The ldap rfc's also define the ldap schema. So you know that you will
always find the user's mail address in the mail attribute, not in whatever
attribute a specific service/vendor decided to place it in. So your
applications will work everywhere and you keep your development costs at a
minimum.
3. ldap servers provide quite nice and powerfull access control as well as a
number of quite helpfull ldap controls and extended operations.
4. Multimaster, multiserver, LAN or MAN replication works perfect (not to say
that you can't do the same with sql).
5. There's the LDAP BIND operation (which can be done securely through SSL)
which allows you to check the user password without having to access the
encrypted one. That's good for security.
Points [1] and [2] are the most important ones.
>
> > > are using different configurations and it could make their
> administration of
> > > the system easier if it had a more flexible capability.
> >
> > As i said before realm,sql,ldap configuration are more than plenty and i
> would
> > require freeradius users to be able to do such configurations.
> >
> > >
> > > 3. I am curious - why have all of the settings for NAS attributes in
> the
> > > New User section AND in the New Group section - would it not make it
> cleaner
> > > overall to just have the NAS attributes contained in just the groups
> section
> > > and if there is a specific requirement for an individual user to have
> > > specfic NAS attribute requirements just have a group of their own???
> It
> > > seems to me it is more confusing to someone new to the freeradius system
> to
> > > have both locations where NAS attributes can be set instead of just the
> > > requirement that the user have a unique group (the group name could be
> the
> > > username) for NAS attributes and all other users that have the same NAS
> > > attribute requirements be in the same group with thost NAS attributes
> > > identified?
> >
> > First of all group support was a feature added on the road, not something
> > present from the start. Also ldap does not require such a configuration.
> > Finally, the current structure goes from general to specific:
> > You can change settings for a whole group, or you can change settings for
> a
> > specific user if that's what you require. I personally like that logic. It
> could
> > be only me though...
> >
>
> Makes sense! I was thinking more along the lines of general group settings
> for groups of users then setting up a unique group for specific user
> attribute settings - not being aware that groups came after the original
> user configuration was my stumbling block...
>
> > >
> > > You wanted to know some specifics [grin]...
> > >
> > > As for the warning message about variables not being defined - current
> > > thinking is if there is a variable that is checked within the body of a
> > > script but is not passed to the script you should at least test to see
> if
> > > the variable exists and if not define the varible with a default value -
> the
> > > reason is to preclude someone attempting to hack the script ( of course
> you
> > > should also test the variables passed to the script to make sure the
> values
> > > being passed are within the range you expect as well and take
> appropriate
> > > action if it is not - there is currently a buffer overflow in the
> maximum
> > > memory used section of PHP prior to the current release that can allow a
> > > hacker total access to the computer! - this was just released in the
> last
> > > few days in the security mailing lists I belong to... ).
> >
> > I am aware of the security risks. I try to make sure that users cannot do
> > 'clever' things with the system. I am currently going through the code and
> > fixing a few open issues when sessions are used. In general there are only
> very
> > few user supplied variables, the rest are unset before being created for
> the
> > first time (so that the user can't pass them through a variable in the
> url) and
> > these user supplied variables are checked that they are of a correct form.
> And i
> > will be going through all the code in the next days to do one more check.
> >
>
> Glad to hear it! I went back and turned on all errors displayed in my
> version of PHP and did not get one single error message reported (PHP
> version 4.1.1 - which is being upgraded to latest today)... Most of the
> time I have seen warnings but they were before I got the system configured
> to the requirements of the dialup_admin installation (and the database
> configured with the tables needed)...
>
> > >
> > > Now - having said all that I think you did a pretty good job on the
> > > dialup_admin overall!!!
> >
> > That's good to hear.
> >
> > >
> > > I read a posting here about modularizing the program to allow easier
> > > modification - that would be a nice thing but not totally a
> requirement...
> >
> > As i answered to that posting, i think it's quite modular already. If you
> think
> > otherwise please explain.
> >
>
> Well - there are two schools of thought on "how" to setup programs such as
> this:
>
> 1. Use the method you have used to embed the application processing code
> within the html presentation code.
>
> 2. Separate the application processing code from the html presentation code.
>
> Is it worth going to the trouble to implement the separation of the
> processing code from the presentation code in dialup_admin??? That is the
> question - for me, probably not - for someone not versed in PHP - maybe, but
> only if they wanted to change the presentation of the display.
There was a time when i was thinking about multilanguaged dialupadmin, themes
and things like that. Eventually i came to the conclusion that it involved too
much work for a small gain.
>
> As for any other "modularizing" I am not sure how much more you would want
> to do - at some point it gets to be too hard to follow the process flow of
> the program and that makes things more difficult to modify (hack) and debug
> (constant module jumping)...
>
> > > It does need better documentation but what program does not???
> >
> > There is a readme and a howto and i try to keep the configuration files as
> > commented as i can. In any case that's an area were help is highly needed.
> >
> > > More comments in the body of the scripts would be a nice addition just
> so
> > > someone can follow the thought-process as to why things are done the way
> > > they are...
> >
> > I agree
> >
> > >
> > > Please take this in the manner in which it is intended - I am not
> flaming
> > > the program at all!!!
> >
> > I don't think you are.
> >
> > >
> > > gm...
> > >
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
