Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
Gary Gatten wrote: Good point about configuring multiple things at once - but that is a recipe - right? Several ingredients that make a tasty cake? Yes. It should be done as a recipe with multiple steps. See http://deployingradius.com for examples. I think it would be a pretty common deployment scenario: lots of people have Cisco and AD, and want to auth their Cisco admins / VTY access against AD. We used this exact scenario as a basic starting point with FR (and I've noticed others on here do the same) before moving on to more complicated setups. Sure. But the layout should be: (1) configuring Active Directory (2) group checking via AD (3) configuring FR to do VTY access *independent* of anything else! (4) Using steps 1-3 to create a combined configuration I've seen too many guides which put all of 1-4 into one guide. The result is that anyone doing something a *little* bit different is lost. For your suggested doc, it should be easy. (1) and (2) exist already. Just refer to them. Then, create a simple doc for (3), using the users file as an example, with local password and no group checking. Then, write (4) showing how you've changed the users file entry from (3) to use the features of (1) and (2). Each step should be no more than a page or so of text, with configuration file examples, instructions on what to type, and explanations as to what it all means. Again, the deployingradius.com docs should be used as an example of layout and style. In the last 6 years, the only complaints about those docs have been (1) typos, and (2) people who didn't follow the steps correctly. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
On 16/05/11 20:26, Alan DeKok wrote: My $0.02 is that we should use github. They now support git-backed Wikis, which use markdown. It's close enough, and has a lot of benefits. I quite like Markdown. We have some internal introduction to radius and introduction to FreeRADIUS documents. If there is consensus on documentation structure, I can try to start putting some stuff together. If someone wants to start off with the basic doc structures, I'll make some time to write some docs. Recipies I like the idea of, but it strikes me that a bit of work with the existing module/unlang/configurable-failover docs would go a long way to explaining how FreeRADIUS processes a request, and how to accomplish what you want (i.e. put the right modules in the right order!) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
documentation and project organization (Was: Using LDAP with EAP-TLS)
On 05/16/2011 10:13 AM, Alexandros Gougousoudis wrote: Phil, I also understand a lot of things and I can read, but the documentation of FR is not ideal. I've googled around, looked examples and had more questions than before. Where are all these features documented, like the if then-things in the conf, all the keywords like ok=return and so on, what's the difference between Autz-Type and Auth-Type? The only thing to get help is here on the list, on the net you find a lot infos to FR 1.1 and 2 (one is deployinradius and one the FR site) sites containing a little bit information, no much more than the conf-files coming with the FR-archive. I'am not complaining, because it's an open source project, but you should note that it's sometimes not the lack of understanding than the lack of well documented features. And if I can't find the infos I need in the docs, I start to try things out. +1 I have to agree, the lack of comprehensive documentation, including an overview of concepts and the flow of operations is the greatest impediment to the success of FreeRADIUS as an open source project. The power and flexibility of FreeRADIUS is awesome, Alan and the other developers have done a wonderful job of providing the open source community with a fantastic piece of critical software. They have excelled at constant innovation and timely bug fixes. The response on the mailing is exceptional. But all these positive attributes are sometimes negated by the difficulty of understanding the system. Many justifiably feel configuring FreeRADIUS is a black art. It's often been pointed out that config files, doc directory and the wiki contains all you need to know. There is a modicum of truth in that. But the reality is it's very difficult to locate, extract, interpret and interpolate the missing pieces to form a functioning mental model in order to accomplish a specific deployment task. I've worked with FreeRADIUS for a while now and I'm still confounded things I don't know, incorrect expectations of behavior (e.g. != does not work for group testing). There are things which as far as I can tell are simply not documented. Just last week I had to help someone who was frustrated by the inability to add attributes to successfully proxied Auth-Accept's using a users file. By reading the source I found the postproxy_users_file config, as far as I could tell this is completely undocumented. When it comes to supporting users Use the source Luke isn't viable. I'd like to suggest the next most import task item for the team is not the 3.0 release, it's not any change to the code base. Rather the single most import task is producing comprehensive documentation collected in a single location augmented with cookbook examples of how to solve common deployment problems. I'll wager the time spent on this list answering questions will greatly diminish thus providing free time for feature enhancements and bug fixes. I'm also concerned at the obvious frustration expressed countless times on this list were folks have spent days, weeks, or in some cases months beating their heads against the wall in frustration. There will be a tipping point at some point in the future where that frustration will doom the project as it gets replaced by an alternative or forked. I've been in open source long enough to have seen this scenario play out multiple times. Just my 2 cents, worth what you paid for it :-) I'll now return you to your regular scheduled programming :-) And in case you missed it above, Alan and everyone else have done a wonderful job and provided a fantastic service to the community. All I'm suggesting here is the task priorities need to be tweaked a bit. P.S.: One thing which has been lacking in the project is public list of the project team. One might make the assumption Alan is the sole contributor, if so then that's truly amazing. But I'm going to guess others are involved. We would like to thank them as well and perhaps have some more insight into the project's organization. At best all I've been able to do in intuit based on reading this list and the dev list over an extended period that some list participants seem to have such an extensive knowledge it suggests to me they must be on the development team, either that or just like myself they've spent a lot of time reading the source code out of necessity. Questions like, what is the project's timeline, what is upcoming in new releases, what is the anticipated release schedule, how is the project organized, who are significant players and what are their roles are information unusually published by open source projects but have been missing (maybe just another example of missing documentation?). -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
Hi John, Just to chime in, I find all of the comments in radiusd.conf, etc. distracting overwhelming. I strip out the comments from the files I'm using - usually to find out how simple the configuration really is. When I'm missing something, I refer back to the original files look up the relevant comment entry. I would prefer all of the comments be assembled into straightforward documentation, using examples for the appropriate configuration sections. My 2 cents, as we say... -John On 05/16/2011 11:20 AM, John Dennis wrote: On 05/16/2011 10:13 AM, Alexandros Gougousoudis wrote: Phil, I also understand a lot of things and I can read, but the documentation of FR is not ideal. I've googled around, looked examples and had more questions than before. Where are all these features documented, like the if then-things in the conf, all the keywords like ok=return and so on, what's the difference between Autz-Type and Auth-Type? The only thing to get help is here on the list, on the net you find a lot infos to FR 1.1 and 2 (one is deployinradius and one the FR site) sites containing a little bit information, no much more than the conf-files coming with the FR-archive. I'am not complaining, because it's an open source project, but you should note that it's sometimes not the lack of understanding than the lack of well documented features. And if I can't find the infos I need in the docs, I start to try things out. +1 I have to agree, the lack of comprehensive documentation, including an overview of concepts and the flow of operations is the greatest impediment to the success of FreeRADIUS as an open source project. The power and flexibility of FreeRADIUS is awesome, Alan and the other developers have done a wonderful job of providing the open source community with a fantastic piece of critical software. They have excelled at constant innovation and timely bug fixes. The response on the mailing is exceptional. But all these positive attributes are sometimes negated by the difficulty of understanding the system. Many justifiably feel configuring FreeRADIUS is a black art. It's often been pointed out that config files, doc directory and the wiki contains all you need to know. There is a modicum of truth in that. But the reality is it's very difficult to locate, extract, interpret and interpolate the missing pieces to form a functioning mental model in order to accomplish a specific deployment task. I've worked with FreeRADIUS for a while now and I'm still confounded things I don't know, incorrect expectations of behavior (e.g. != does not work for group testing). There are things which as far as I can tell are simply not documented. Just last week I had to help someone who was frustrated by the inability to add attributes to successfully proxied Auth-Accept's using a users file. By reading the source I found the postproxy_users_file config, as far as I could tell this is completely undocumented. When it comes to supporting users Use the source Luke isn't viable. I'd like to suggest the next most import task item for the team is not the 3.0 release, it's not any change to the code base. Rather the single most import task is producing comprehensive documentation collected in a single location augmented with cookbook examples of how to solve common deployment problems. I'll wager the time spent on this list answering questions will greatly diminish thus providing free time for feature enhancements and bug fixes. I'm also concerned at the obvious frustration expressed countless times on this list were folks have spent days, weeks, or in some cases months beating their heads against the wall in frustration. There will be a tipping point at some point in the future where that frustration will doom the project as it gets replaced by an alternative or forked. I've been in open source long enough to have seen this scenario play out multiple times. Just my 2 cents, worth what you paid for it :-) I'll now return you to your regular scheduled programming :-) And in case you missed it above, Alan and everyone else have done a wonderful job and provided a fantastic service to the community. All I'm suggesting here is the task priorities need to be tweaked a bit. P.S.: One thing which has been lacking in the project is public list of the project team. One might make the assumption Alan is the sole contributor, if so then that's truly amazing. But I'm going to guess others are involved. We would like to thank them as well and perhaps have some more insight into the project's organization. At best all I've been able to do in intuit based on reading this list and the dev list over an extended period that some list participants seem to have such an extensive knowledge it suggests to me they must be on the development team, either that or just like myself they've spent a lot of time reading the source code out of necessity. Questions like, what is the project's timeline, what is upcoming in new
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
John, I believe Alan started a project to try and improve documentation in May last year. A few documents were converted RST format, but I don't think it was ever completed. I'm going to suggest the same thing I did back then. Add RST support to the Wiki, setup a well defined documentation structure (as in these are the subjects and example configurations that should be covered), and then roll page exports from the wiki into the documentation that 'ships' with FreeRADIUS. There's so much to document that it needs to be a collaborative effort. -Arran Arran Cudbard-Bell RM-RF Limited - Security consultation and contracting VoIP: +1 916-436-1352 Cell: +44 7854041841 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
On 05/16/2011 02:20 PM, Arran Cudbard-Bell wrote: John, I believe Alan started a project to try and improve documentation in May last year. A few documents were converted RST format, but I don't think it was ever completed. I'm going to suggest the same thing I did back then. Add RST support to the Wiki, setup a well defined documentation structure (as in these are the subjects and example configurations that should be covered), and then roll page exports from the wiki into the documentation that 'ships' with FreeRADIUS. There's so much to document that it needs to be a collaborative effort. Sounds like a fine plan to me. I do recall the documentation effort from last year. But the various promises of documentation seem to wither on the vine, the effort you cite is a perfect example. Maybe Alan's book is the answer, but that's been promised for a long time too. My basic take this is the classic developer's dilemma, developers want to write code, not documentation. When time allocation occurs the choice is to write code and defer the doc. But doc must get done, it needs an owner who is going to own the task and get it done. FWIW, I constantly get complaints about the difficulty of using FreeRADIUS and the lack of usable documentation. Only last week this reached all the way to my manager who had to intervene and assert this is an upstream project issue and not something Red Hat can fix. Sorry, just being the messenger, just trying to ultimately help by saying there is a pain point and not sweep it under the rug. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: documentation and project organization (Was: Using LDAP with EAP-TLS)
If I knew more about it I would take my time to write some ... examples, use cases, case studies, whatever. But, I can barely get by - each time I think I understand something it turns out I really don't. I don't want to spread bad info so I say nothing - usually :) IMHO a good starting point would be a single point of all authorized documentation: freeradius.org, Wiki, don't care - but it's frustrating when you find doc that seems legit that conflicts with other doc that also seems legit. The single source of info then needs to have whatever is there vetted by those that actually KNOW whats what and kept current. Unfortunately most people don't understand the details of PEAP, *CHAP, GTC, certs, etc. so they simply follow instructions verbatim. If those instructions are wrong, skip some steps, or even have basic typo's: it will lead to a lot of frustration not only to the novice user, but the smart people on here that constantly address the same simple issues. I will step up to the plate and offer up a standard format for a Recipe. I will pick an easy deployment scenario - such as: How do I configure FR to authenticate VTY access to my Cisco gear using AD on the backend, and users must be a member of GroupX I'm sure I will get some things wrong, but perhaps we can at least settle on a common template/format which will at least help moving forward. -Original Message- From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell@lists.freeradius.org] On Behalf Of John Dennis Sent: Monday, May 16, 2011 1:52 PM To: FreeRadius users mailing list Subject: Re: documentation and project organization (Was: Using LDAP with EAP-TLS) On 05/16/2011 02:20 PM, Arran Cudbard-Bell wrote: John, I believe Alan started a project to try and improve documentation in May last year. A few documents were converted RST format, but I don't think it was ever completed. I'm going to suggest the same thing I did back then. Add RST support to the Wiki, setup a well defined documentation structure (as in these are the subjects and example configurations that should be covered), and then roll page exports from the wiki into the documentation that 'ships' with FreeRADIUS. There's so much to document that it needs to be a collaborative effort. Sounds like a fine plan to me. I do recall the documentation effort from last year. But the various promises of documentation seem to wither on the vine, the effort you cite is a perfect example. Maybe Alan's book is the answer, but that's been promised for a long time too. My basic take this is the classic developer's dilemma, developers want to write code, not documentation. When time allocation occurs the choice is to write code and defer the doc. But doc must get done, it needs an owner who is going to own the task and get it done. FWIW, I constantly get complaints about the difficulty of using FreeRADIUS and the lack of usable documentation. Only last week this reached all the way to my manager who had to intervene and assert this is an upstream project issue and not something Red Hat can fix. Sorry, just being the messenger, just trying to ultimately help by saying there is a pain point and not sweep it under the rug. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html font size=1 div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in' /div This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. /font - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
Arran Cudbard-Bell wrote: I believe Alan started a project to try and improve documentation in May last year. A few documents were converted RST format, but I don't think it was ever completed. I received a number of patches from one person, a few from another one or two, and nothing else. I've been saying for ~10 years that this is a community effort. I'd *like* additional documentation, but I don't get paid to write it. I get paid to write code. The community has spoken: documentation isn't important enough. I'd like to change that, but I'm busy. I'm going to suggest the same thing I did back then. Add RST support to the Wiki, setup a well defined documentation structure (as in these are the subjects and example configurations that should be covered), and then roll page exports from the wiki into the documentation that 'ships' with FreeRADIUS. My $0.02 is that we should use github. They now support git-backed Wikis, which use markdown. It's close enough, and has a lot of benefits. But it requires converting the existing Wiki pages. I'm not inclined to do it, as I have too many other things to do. There's so much to document that it needs to be a collaborative effort. It's not hard. Read the comments in the config files, and write a document summarizing them. Add one or two simple examples. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
John Dennis wrote: Sounds like a fine plan to me. I do recall the documentation effort from last year. But the various promises of documentation seem to wither on the vine, the effort you cite is a perfect example. Maybe Alan's book is the answer, but that's been promised for a long time too. I had planned on finishing it this spring. I got busy, in a you don't want to know kind of way. FWIW, I constantly get complaints about the difficulty of using FreeRADIUS and the lack of usable documentation. Only last week this reached all the way to my manager who had to intervene and assert this is an upstream project issue and not something Red Hat can fix. Sorry, just being the messenger, just trying to ultimately help by saying there is a pain point and not sweep it under the rug. If the customers care, refer them to me. If it's a priority for them, someone can be found to do the work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
Gary Gatten wrote: I will step up to the plate and offer up a standard format for a Recipe. I will pick an easy deployment scenario - such as: How do I configure FR to authenticate VTY access to my Cisco gear using AD on the backend, and users must be a member of GroupX That's configuring 4 things at once... people will find it useful, but my worry is that it's too specific. I'm sure I will get some things wrong, but perhaps we can at least settle on a common template/format which will at least help moving forward. A template recipe sounds like a wonderful idea. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
John Center wrote: Just to chime in, I find all of the comments in radiusd.conf, etc. distracting overwhelming. I strip out the comments from the files I'm using - usually to find out how simple the configuration really is. When I'm missing something, I refer back to the original files look up the relevant comment entry. I would prefer all of the comments be assembled into straightforward documentation, using examples for the appropriate configuration sections. Sure. Submit a patch. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
John Dennis wrote: But all these positive attributes are sometimes negated by the difficulty of understanding the system. Many justifiably feel configuring FreeRADIUS is a black art. It's often been pointed out that config files, doc directory and the wiki contains all you need to know. There is a modicum of truth in that. But the reality is it's very difficult to locate, extract, interpret and interpolate the missing pieces to form a functioning mental model in order to accomplish a specific deployment task. Yup. I've worked with FreeRADIUS for a while now and I'm still confounded things I don't know, incorrect expectations of behavior (e.g. != does not work for group testing). There are things which as far as I can tell are simply not documented. Oh yes, lots. Just last week I had to help someone who was frustrated by the inability to add attributes to successfully proxied Auth-Accept's using a users file. By reading the source I found the postproxy_users_file config, as far as I could tell this is completely undocumented. When it comes to supporting users Use the source Luke isn't viable. Yes, well... there isn't much to argue with there. I'd like to suggest the next most import task item for the team is not the 3.0 release, it's not any change to the code base. Rather the single most import task is producing comprehensive documentation collected in a single location augmented with cookbook examples of how to solve common deployment problems. Sure. Except that 3.0 is pretty much ready now. I'll wager the time spent on this list answering questions will greatly diminish thus providing free time for feature enhancements and bug fixes. For me, time on the list is 30 seconds in between other work. i.e. wait for compile: answer post. It's really quite minimal, despite the volume of messages I send. I'm also concerned at the obvious frustration expressed countless times on this list were folks have spent days, weeks, or in some cases months beating their heads against the wall in frustration. There will be a tipping point at some point in the future where that frustration will doom the project as it gets replaced by an alternative or forked. I've been in open source long enough to have seen this scenario play out multiple times. The level of frustration has diminished significantly with 2.0, and again with 2.1. The default configurations just work, and the debug messages have been improved to the point where mere mortals can understand them. One thing which has been lacking in the project is public list of the project team. One might make the assumption Alan is the sole contributor, if so then that's truly amazing. Look at github. The only person other than me who's had meaningful contributions in the last 2 years is Phil Mayers. Many other authors listed (e.g. Dante) are contractual obligations, implemented by me. But I'm going to guess others are involved. We would like to thank them as well and perhaps have some more insight into the project's organization. At best all I've been able to do in intuit based on reading this list and the dev list over an extended period that some list participants seem to have such an extensive knowledge it suggests to me they must be on the development team, either that or just like myself they've spent a lot of time reading the source code out of necessity. There are a number of people who run multiple RADIUS servers (machines products) for their living. They're familiar with pretty much everything. We're all in their debt for answers, docs, bug reports, bug fixes, etc. Questions like, what is the project's timeline, what is upcoming in new releases, what is the anticipated release schedule, how is the project organized, who are significant players and what are their roles are information unusually published by open source projects but have been missing (maybe just another example of missing documentation?). Project timeline: whenever What's upcoming: see doc/ChangeLog in git. release schedule: usually every 3-4 months organization / people / roles: code: Alan mgmt: Alan docs: Alan web site: Alan releases: Alan bug fixes: Alan Wiki: Peter Nixon Sense a theme? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: documentation and project organization (Was: Using LDAP with EAP-TLS)
Good point about configuring multiple things at once - but that is a recipe - right? Several ingredients that make a tasty cake? I think it would be a pretty common deployment scenario: lots of people have Cisco and AD, and want to auth their Cisco admins / VTY access against AD. We used this exact scenario as a basic starting point with FR (and I've noticed others on here do the same) before moving on to more complicated setups. I probably should doc some stuff for internal use regardless, so even if no one else finds it useful it won't be a waste of time. G -Original Message- From: freeradius-users-bounces+ggatten=waddell@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Monday, May 16, 2011 2:31 PM To: FreeRadius users mailing list Subject: Re: documentation and project organization (Was: Using LDAP with EAP-TLS) Gary Gatten wrote: I will step up to the plate and offer up a standard format for a Recipe. I will pick an easy deployment scenario - such as: How do I configure FR to authenticate VTY access to my Cisco gear using AD on the backend, and users must be a member of GroupX That's configuring 4 things at once... people will find it useful, but my worry is that it's too specific. I'm sure I will get some things wrong, but perhaps we can at least settle on a common template/format which will at least help moving forward. A template recipe sounds like a wonderful idea. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html font size=1 div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in' /div This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. /font - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
On 05/16/2011 03:41 PM, Alan DeKok wrote: organization / people / roles: code: Alan mgmt: Alan docs: Alan web site: Alan releases: Alan bug fixes: Alan Wiki: Peter Nixon Sense a theme? I do see a theme but I also see a problem. FreeRADIUS has gotten big enough that 1 person, even one as amazing as you are, can't do it all. I humbly suggest you try to offload some of the work by running this as a project and having a team. You can delegate responsibilities, coordinate and still have a significant architectural and coding role. Plus you get the added benefit of being Benevolent Dictator for Life of FreeRADIUS (http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life) -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: documentation and project organization (Was: Using LDAP with EAP-TLS)
John Dennis wrote: I do see a theme but I also see a problem. FreeRADIUS has gotten big enough that 1 person, even one as amazing as you are, can't do it all. I humbly suggest you try to offload some of the work by running this as a project and having a team. Sure. Volunteers? It was run as a team for a while. The main team members gradually got busy doing other things. You can delegate responsibilities, coordinate and still have a significant architectural and coding role. Sure. Using git means that delegation is much less of an issue, though. Simply fork FreeRADIUS using github, write patches, and submit them. That's how all of the recent third-party patches have gone in. Again: look at the track record. Pretty much any interesting new feature, or patch or bugfix gets added. But the volume of such submissions is pretty low. There's no need to volunteer, or to take on a role. Just do the work, and the title will come automatically. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
