Kostas,
Hopefully this is still in the context of freeradius for this list...
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...
> 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...
> 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??? 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.
> > 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.
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...
> >
> > ----- Original Message -----
> > From: "Kostas Kalevras" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, July 23, 2004 6:36 PM
> > Subject: Re: New Opensource project-AAAadmin
> >
> >
> > > On Fri, 23 Jul 2004, Gary McKinney wrote:
> > >
> > > > Kostas,
> > > >
> > > > Are you also a user too??? [grin]...
> > >
> > > Yes, dialupadmin is used in both my university (ntua.gr/15000 users)
and
> > in the
> > > greek school network (sch.gr/150000 users). In the latter there are
around
> > 100
> > > people using it (delegated user administration) with no problems.
> > >
> > > I wrote dialupadmin cause i needed it.
> > >
> > > >
> > > > Kidding aside - is there some place where the dialup_admin is being
> > > > maintained (CVS) and where freatures can be added to the code (not
to
> > > > mention bringing the code up to current levels) ???
> > >
> > > Have you tried freeradius CVS? dialup_admin is RIGHT there.
> > >
> > > And please, when someone speaks about bringing the code to current
> > levels,adding
> > > features,making it stable,wearing dialupadmin a nice skirt can you
please
> > be
> > > specific? I am quite tired of people criticizing dialupadmin or any
other
> > piece
> > > of freeradius without specifying what they think is wrong or lacking.
> > Obviously
> > > the last one was not something personal, it's just that i am getting
quite
> > tired
> > > of criticism without any suggestions.
> > >
> > > >
> > > > BTW: I have not setup the database side completely yet but you can
see
> > the
> > > > latest version of dialup_admin at the following url:
> > > > http://www.ewcllc.net/dialup - like I said, I have not completely
set
> > this
> > > > up yet but it is better than plain ole screen shots [grin]...
> > >
> > > That's quite nice.
> > >
> > > >
> > > > gm...
> > > >
> > > > ----- Original Message -----
> > > > From: "Kostas Kalevras" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Friday, July 23, 2004 9:11 AM
> > > > Subject: Re: New Opensource project-AAAadmin
> > > >
> > > >
> > > > > On Fri, 23 Jul 2004, Amit Gupta wrote:
> > > > >
> > > > > > are you currently using dailupadmin
> > > > >
> > > > > Actually i am the writer.
> > > > >
> > > > > Kostas Kalevras Network Operations Center
> > > > > [EMAIL PROTECTED] National Technical University of Athens, Greece
> > > > > Work Phone: +30 210 7721861
> > > > > 'Go back to the shadow' Gandalf
<snip> removed excess
---
[This E-mail scanned for viruses by Declude Ant-Virus Scanner]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
