It seems that in addition to virtual server blocks I can also define global clients in a site file. I'd really like to contain all of the configuration specific to my site in one file, including modules. But it doesn't seem like I can define global modules in a site file. Is this correct? I can't find any description of what is actually allowed in such a file; just a description of what is allowed in a virtual server block.
On Apr 14, 2015, at 9:27 AM, James Sumners <james.sumners@clayton.edu> wrote:
It seems that in addition to virtual server blocks I can also define global clients in a site file. I'd really like to contain all of the configuration specific to my site in one file, including modules. But it doesn't seem like I can define global modules in a site file. Is this correct? I can't find any description of what is actually allowed in such a file; just a description of what is allowed in a virtual server block.
The documentation and examples should make this clear. If an example has something in a virtual server, then it's allowed to be there. Otherwise it's not. You CAN put clients into a sub-section, and then tie them to a "listen" section. And then tie the listen section to a virtual server. This is documented. See raddb/sites-available/README Alan DeKok.
On 14/04/15 14:27, James Sumners wrote:
It seems that in addition to virtual server blocks I can also define global clients in a site file. I'd really like to contain all of the configuration specific to my site in one file, including modules. But it doesn't seem like I can define global modules in a site file. Is this correct? I can't find any description of what is actually allowed in such a file; just a description of what is allowed in a virtual server block.
The sites-enabled/x files are just includes; you can put anything in there that's valid in an include. You can't define a module because you can't have multiple modules {} sections, i.e. this: radiusd.conf: modules { a b } include sites-enabled/x x: modules { c d } ...doesn't make sense. You can define listen/client/server blocks in sites-enabled/x because you can have miltiple listen/client/server blocks. In other words, you can put anything that would be valid if you wrote it in one big file, in the order it was included.
On 2015-04-14 13:54:15 +0000, Phil Mayers said:
On 14/04/15 14:27, James Sumners wrote:
It seems that in addition to virtual server blocks I can also define global clients in a site file. I'd really like to contain all of the configuration specific to my site in one file, including modules. But it doesn't seem like I can define global modules in a site file. Is this correct? I can't find any description of what is actually allowed in such a file; just a description of what is allowed in a virtual server block.
The sites-enabled/x files are just includes; you can put anything in there that's valid in an include.
You can't define a module because you can't have multiple modules {} sections, i.e. this:
radiusd.conf:
modules { a b } include sites-enabled/x
x:
modules { c d }
...doesn't make sense. You can define listen/client/server blocks in sites-enabled/x because you can have miltiple listen/client/server blocks.
In other words, you can put anything that would be valid if you wrote it in one big file, in the order it was included.
Okay, that's the way I thought it would work. I just didn't know that you can't have multiple `modules` blocks. If there's some documentation that details that, I haven't seen it.
On Apr 14, 2015, at 10:02 AM, James Sumners <james.sumners@clayton.edu> wrote:
Okay, that's the way I thought it would work. I just didn't know that you can't have multiple `modules` blocks. If there's some documentation that details that, I haven't seen it.
See radiusd.conf. It says that modules are loaded from the "modules" block. It *doesn't* say that you cannot put modules elsewhere. The examples show what's possible. Because that's simple and limited. They *don't* list all of the configurations that won't work. Because those are infinite. Alan DeKok.
On 2015-04-14 16:06:40 +0000, Alan DeKok said:
On Apr 14, 2015, at 10:02 AM, James Sumners <james.sumners@clayton.edu> wrote:
Okay, that's the way I thought it would work. I just didn't know that you can't have multiple `modules` blocks. If there's some documentation that details that, I haven't seen it.
See radiusd.conf. It says that modules are loaded from the "modules" block. It *doesn't* say that you cannot put modules elsewhere.
The examples show what's possible. Because that's simple and limited. They *don't* list all of the configurations that won't work. Because those are infinite.
Alan DeKok.
It's pretty simple to indicate how many times a block can be used in the configuration: once or multiple. Asking users to infer this from the 200 or so configuration files that double as the documentation is, frankly, ridiculous. I'll break down what led to the orginal post in this thread: 1) I read the thread where someone was having an issue with rlm_memcached 2) I tried to investigate this module as I could be interested in using it 3) I go to the web site to read the documenation 4) I browse through the few man pages on the site that don't 404 5) I see that the few documented modules indicate that their configuration can be included in a `modules` block 6) I realize that my site file also contains global definitions for clients 7) I attempt to move one of my `mods-enabled` configs to the global space of my site file 8) Failure 9) Spend 45 minutes trying to find documentation to figure out the problem 10) Give up and post to this list
On Apr 14, 2015, at 1:01 PM, James Sumners <james.sumners@clayton.edu> wrote:
It's pretty simple to indicate how many times a block can be used in the configuration: once or multiple. Asking users to infer this from the 200 or so configuration files that double as the documentation is, frankly, ridiculous.
So... asking people to read the configuration files is ridiculous? The radiusd.conf file says "the 'modules' section loads modules". There is NOTHING which says that modules can be located elsewhere. The conclusion should be pretty simple. Unfortunately, some people want to be spoon fed. You can't put "listen" sections into module configurations. You can't put virtual servers into module configurations. You can't put module configurations in virtual servers. You can't put module configurations into client definitions. The list of what is NOT allowed is infinite. The list of what IS allowed is small, and is clearly documented.
I'll break down what led to the orginal post in this thread:
1) I read the thread where someone was having an issue with rlm_memcached 2) I tried to investigate this module as I could be interested in using it 3) I go to the web site to read the documenation 4) I browse through the few man pages on the site that don't 404 5) I see that the few documented modules indicate that their configuration can be included in a `modules` block 6) I realize that my site file also contains global definitions for clients 7) I attempt to move one of my `mods-enabled` configs to the global space of my site file
i.e. NOT reading "radiusd.conf" to see where modules. NOT reading raddb/mods-available/README.rst to see HOW the modules are defined. Instead, just going "I know, I'll starry putting random things into random config files. WTF? It doesn't work? YOU BASTARDS". Forgive me if I don't have a lot of sympathy. While the documentation isn't perfect, I'm continually amazed at the people who look every EXCEPT the documentation that ships with the server. Should I put big warnings on the web pages which say "PLEASE READ THE CONFIG FILES YOU ARE EDITING. IT HELPS" ?
8) Failure 9) Spend 45 minutes trying to find documentation to figure out the problem
Yeah, it's hard work to find the READMEs that come with the server. Things in raddb/mods-available? Woo.... can't look THERE for documentation. That wouldn't make any sense.
10) Give up and post to this list
And get told that a little bit of thought is productive. Which is I think your main point of frustration. Alan DeKok.
On 2015-04-14 17:21:47 +0000, Alan DeKok said:
On Apr 14, 2015, at 1:01 PM, James Sumners <james.sumners@clayton.edu> wrote:
It's pretty simple to indicate how many times a block can be used in the configuration: once or multiple. Asking users to infer this from the 200 or so configuration files that double as the documentation is, frankly, ridiculous.
So... asking people to read the configuration files is ridiculous?
That's not what I said. I said relying on them to be the documenation is ridiculous. There are MANY of them, they are not in any order, are not easily referenced, and it is very easy to get lost in them.
The radiusd.conf file says "the 'modules' section loads modules". There is NOTHING which says that modules can be located elsewhere. The conclusion should be pretty simple.
Unfortunately, some people want to be spoon fed. You can't put "listen" sections into module configurations. You can't put virtual servers into module configurations. You can't put module configurations in virtual servers. You can't put module configurations into client definitions.
Yes, it's unfortunate that the people who didn't develop the product expect the people who did to actually provide information on how to use it.
The list of what is NOT allowed is infinite. The list of what IS allowed is small, and is clearly documented.
I didn't suggest you list the infinite. I suggested you list how the block is interpreted by the config parser. Is a block unique or do subsequent definitions override previous definitions? How difficult is that to understand?
I'll break down what led to the orginal post in this thread:
1) I read the thread where someone was having an issue with rlm_memcached 2) I tried to investigate this module as I could be interested in using it 3) I go to the web site to read the documenation 4) I browse through the few man pages on the site that don't 404 5) I see that the few documented modules indicate that their configuration can be included in a `modules` block 6) I realize that my site file also contains global definitions for clients 7) I attempt to move one of my `mods-enabled` configs to the global space of my site file
i.e. NOT reading "radiusd.conf" to see where modules. NOT reading raddb/mods-available/README.rst to see HOW the modules are defined. Instead, just going "I know, I'll starry putting random things into random config files. WTF? It doesn't work? YOU BASTARDS".
Let's look at an example of the documentation in radiusd.conf: # PROXY CONFIGURATION # # proxy_requests: Turns proxying of RADIUS requests on or off. # # The server has proxying turned on by default. If your system is NOT # set up to proxy requests to another server, then you can turn proxying # off here. This will save a small amount of resources on the server. # # If you have proxying turned off, and your configuration files say # to proxy a request, then an error message will be logged. # # To disable proxying, change the "yes" to "no", and comment the # $INCLUDE line. # # allowed values: {no, yes} Okay, I can turn proxying on or off. Great. What is it useful for? Why would I want to turn it on? "Read proxy.conf" you say? Okay... ####################################################################### # # Proxy server configuration # # This entry controls the servers behaviour towards ALL other servers # to which it sends proxy requests. Uh, wonderful. That's all we get to describe the feature. The rest of the file describes each option (as should be done). It doesn't do anything to explain how to use the feature or why you'd want to.
Forgive me if I don't have a lot of sympathy. While the documentation isn't perfect, I'm continually amazed at the people who look every EXCEPT the documentation that ships with the server.
They're looking elsewhere because the documentation that ships with the server is not sufficient for someone who didn't write the software.
Should I put big warnings on the web pages which say "PLEASE READ THE CONFIG FILES YOU ARE EDITING. IT HELPS" ?
8) Failure 9) Spend 45 minutes trying to find documentation to figure out the problem
Yeah, it's hard work to find the READMEs that come with the server. Things in raddb/mods-available? Woo.... can't look THERE for documentation. That wouldn't make any sense.
No, it doesn't really make sense. In basically every other project the "documentation" in the configuration files is to explain the options defined in those configuration files. That is not the same as describing the features, what they do, and how they work together.
10) Give up and post to this list
And get told that a little bit of thought is productive. Which is I think your main point of frustration.
You know what is meant in the docs you are referencing because you wrote them. You can fill in the gaps because you know what should be in those gaps. Telling the users to infer those with no prior knowledge of how the software works is akin to saying "why don't you know what I'm thinking?" Getting back to this subject of this thread... Phil Mayers actually answered my question. You tried to answer something I didn't even ask: "can clients be defined in a server section?" I knew the answer to that; that part is actually documented. But the example, literally `sites-available/example`, shows client blocks being defined _outside_ of the server block. Thus, it can be inferred, which is you suggestion every time, from that example that other configuration blocks can also be included in the site file. And since I want to modify the shipped configuration files as little as possible, I attempted to contain my modules config in the same way as I evidently could my clients -- in the same file as my server configuration. In short you can't have it both ways: you can't ask us to piece stuff together from the stuff in the config files and then complain when we attempt to do so.
On Apr 14, 2015, at 2:19 PM, James Sumners <james.sumners@clayton.edu> wrote:
That's not what I said. I said relying on them to be the documenation is ridiculous. There are MANY of them, they are not in any order, are not easily referenced, and it is very easy to get lost in them.
Most directories have a README in them. That *should* be clear. Documentation is a problem with most open source projects. Do people complain about it? Yes, lots. Do people contribute? Rarely. So... *do* something about it. I get annoyed at complaints, because most of them can be summarized as "YOU people need to do MORE WORK to make ME happy." Well, no.
The radiusd.conf file says "the 'modules' section loads modules". There is NOTHING which says that modules can be located elsewhere. The conclusion should be pretty simple. Unfortunately, some people want to be spoon fed. You can't put "listen" sections into module configurations. You can't put virtual servers into module configurations. You can't put module configurations in virtual servers. You can't put module configurations into client definitions.
Yes, it's unfortunate that the people who didn't develop the product expect the people who did to actually provide information on how to use it.
i.e. you didn't bother reading radiusd.conf to see how the modules work. You didn't bother looking at the README in raddb/mods-available/. You DID search on google for things. What a great idea! Instead of looking at the documentation SHIPPED WITH THE PRODUCT, you wander around random third-party web sites.
I didn't suggest you list the infinite. I suggested you list how the block is interpreted by the config parser. Is a block unique or do subsequent definitions override previous definitions? How difficult is that to understand?
Like already exists in radiusd.conf? Or raddb/mods-available/README? That you didn't read? How hard is THAT to understand? Honestly.... you're complaining that documentation doesn't exist. When I point out that it does, your response is "LA LA LA But you guys don't have documentation!" <sigh> It's an up-hill battle fighting against people who don't want to learn.
Let's look at an example of the documentation in radiusd.conf:
# PROXY CONFIGURATION
I'll note that you're changing the subject from *module* documentation to *proxy* documentation. There's only one reason to do that. I'm right, and you know it.
They're looking elsewhere because the documentation that ships with the server is not sufficient for someone who didn't write the software.
I guess 10M people who configured the server are all wrong, and you're right.
You know what is meant in the docs you are referencing because you wrote them. You can fill in the gaps because you know what should be in those gaps. Telling the users to infer those with no prior knowledge of how the software works is akin to saying "why don't you know what I'm thinking?"
Yeah, expecting people to read "radiusd.conf" and go from there is asking too much. Pretty much every configuration file in the server explains what it's for, how it works, and how it's used. It's not my fault you don't read them.
Getting back to this subject of this thread... Phil Mayers actually answered my question. You tried to answer something I didn't even ask: "can clients be defined in a server section?" I knew the answer to that; that part is actually documented. But the example, literally `sites-available/example`, shows client blocks being defined _outside_ of the server block. Thus, it can be inferred, which is you suggestion every time, from that example that other configuration blocks can also be included in the site file. And since I want to modify the shipped configuration files as little as possible, I attempted to contain my modules config in the same way as I evidently could my clients -- in the same file as my server configuration.
In short you can't have it both ways: you can't ask us to piece stuff together from the stuff in the config files and then complain when we attempt to do so.
No. I'm pointing out that *your* complaints aren't substantiated by the evidence. And that's why I started on the commercial documentation: http://networkradius.com/doc/ The formatting is a bit ugly, and there are pieces missing. But there's a LOT more documentation than on the Wiki. It's cross-linked and explanatory. It describes (in hundreds of pages) how the server works, how the "authorize" section works, etc. And before you start complaining that it's not perfect and incomplete, I know. It's being worked on. What would you rather have, better (but imperfect) documentation now, or perfect documentation 2 years from now? Alan DeKok.
On 2015-04-14 18:45:52 +0000, Alan DeKok said:
On Apr 14, 2015, at 2:19 PM, James Sumners <james.sumners@clayton.edu> wrote:
That's not what I said. I said relying on them to be the documenation is ridiculous. There are MANY of them, they are not in any order, are not easily referenced, and it is very easy to get lost in them.
Most directories have a README in them. That *should* be clear.
Documentation is a problem with most open source projects. Do people complain about it? Yes, lots. Do people contribute? Rarely.
How am I supposed to do that when I don't know the information? FYI, I did add some links to the expression documenation in wiki articles that mention xlat after reading Arran's reply earlier. Is it much? No, but they should've been there.
So... *do* something about it. I get annoyed at complaints, because most of them can be summarized as "YOU people need to do MORE WORK to make ME happy."
Well, no.
The radiusd.conf file says "the 'modules' section loads modules". There is NOTHING which says that modules can be located elsewhere. The conclusion should be pretty simple. Unfortunately, some people want to be spoon fed. You can't put "listen" sections into module configurations. You can't put virtual servers into module configurations. You can't put module configurations in virtual servers. You can't put module configurations into client definitions.
Yes, it's unfortunate that the people who didn't develop the product expect the people who did to actually provide information on how to use it.
i.e. you didn't bother reading radiusd.conf to see how the modules work. You didn't bother looking at the README in raddb/mods-available/.
You DID search on google for things. What a great idea! Instead of looking at the documentation SHIPPED WITH THE PRODUCT, you wander around random third-party web sites.
I didn't suggest you list the infinite. I suggested you list how the block is interpreted by the config parser. Is a block unique or do subsequent definitions override previous definitions? How difficult is that to understand?
Like already exists in radiusd.conf? Or raddb/mods-available/README? That you didn't read?
I'll play along... Yep, `mods-available/README.rst` does say one word about if the modules config block can be declared more than once, or that it is unique, or even that it exists.
How hard is THAT to understand?
Honestly.... you're complaining that documentation doesn't exist. When I point out that it does, your response is "LA LA LA But you guys don't have documentation!"
<sigh> It's an up-hill battle fighting against people who don't want to learn.
Let's look at an example of the documentation in radiusd.conf:
# PROXY CONFIGURATION
I'll note that you're changing the subject from *module* documentation to *proxy* documentation. There's only one reason to do that. I'm right, and you know it.
What more did you want me to write on the modules section in radiusd.conf? You wrote basically everything it says for the introduction in the post I replied to. Do you want me to just quote back your own examples?
They're looking elsewhere because the documentation that ships with the server is not sufficient for someone who didn't write the software.
I guess 10M people who configured the server are all wrong, and you're right.
I'd venture to guess that many are rolling along with out-of-the-box configurations and haven't bother to try to understand them at all. Most have probably hen pecked through and changed names and URLs to match their environment.
You know what is meant in the docs you are referencing because you wrote them. You can fill in the gaps because you know what should be in those gaps. Telling the users to infer those with no prior knowledge of how the software works is akin to saying "why don't you know what I'm thinking?"
Yeah, expecting people to read "radiusd.conf" and go from there is asking too much.
Pretty much every configuration file in the server explains what it's for, how it works, and how it's used. It's not my fault you don't read them.
Getting back to this subject of this thread... Phil Mayers actually answered my question. You tried to answer something I didn't even ask: "can clients be defined in a server section?" I knew the answer to that; that part is actually documented. But the example, literally `sites-available/example`, shows client blocks being defined _outside_ of the server block. Thus, it can be inferred, which is you suggestion every time, from that example that other configuration blocks can also be included in the site file. And since I want to modify the shipped configuration files as little as possible, I attempted to contain my modules config in the same way as I evidently could my clients -- in the same file as my server configuration.
In short you can't have it both ways: you can't ask us to piece stuff together from the stuff in the config files and then complain when we attempt to do so.
No. I'm pointing out that *your* complaints aren't substantiated by the evidence.
And that's why I started on the commercial documentation: http://networkradius.com/doc/
The formatting is a bit ugly, and there are pieces missing. But there's a LOT more documentation than on the Wiki. It's cross-linked and explanatory. It describes (in hundreds of pages) how the server works, how the "authorize" section works, etc.
And before you start complaining that it's not perfect and incomplete, I know. It's being worked on. What would you rather have, better (but imperfect) documentation now, or perfect documentation 2 years from now?
http://networkradius.com/doc/3.0.7/ is looking pretty good. It should probably be linked in the top level README, but that seems to be for documenting changes from previous versions. But, really, why would you have needed to start writing that site if what I'm saying isn't at least partially true?
On Apr 14, 2015, at 3:30 PM, James Sumners <james.sumners@clayton.edu> wrote:
Documentation is a problem with most open source projects. Do people complain about it? Yes, lots. Do people contribute? Rarely.
How am I supposed to do that when I don't know the information?
Learn, then contribute. Instead, the process typically goes: learn, move on to other projects.
Yep, `mods-available/README.rst` does say one word about if the modules config block can be declared more than once, or that it is unique, or even that it exists.
<sigh> And radiusd.conf? I told you to look there, too. # MODULE CONFIGURATION # # The names and configuration of each module is located in this section. # # After the modules are defined here, they may be referred to by name, # in other sections of this configuration file. ... i.e. MODULES ARE DEFINED HERE. Not "they can be defined in multiple places". But THEY ARE HERE. Full stop. All it takes is 5 minutes reading to THINK, and conclude that they likely can't be put anywhere else. Your stubbornness here is telling. This is about the fourth time I've said it's documented in radiusd.conf. Yet you insist on looking in the wrong place. Again, and again, and again. This is also typical. The people who complain the most are the ones who fight hardest against being educated.
I'll note that you're changing the subject from *module* documentation to *proxy* documentation. There's only one reason to do that. I'm right, and you know it.
What more did you want me to write on the modules section in radiusd.conf? You wrote basically everything it says for the introduction in the post I replied to. Do you want me to just quote back your own examples?
Don't be obtuse. You claimed the docs didn't exist. I pointed out that they do. And you didn't read them. Instead of saying "you're right, I didn't look there", you changed the subject to "But the OTHER documentation I never mentioned sucks, too". This is dishonest. It's also typical of people who fight hard against being educated.
http://networkradius.com/doc/3.0.7/ is looking pretty good. It should probably be linked in the top level README, but that seems to be for documenting changes from previous versions.
But, really, why would you have needed to start writing that site if what I'm saying isn't at least partially true?
I never said the documentation was perfect. I said that YOUR ISSUES were answered in the documentation. Which they are. The commercial documentation is there because it's intended to contain excruciating levels of detail. Detail that requires a paid person to spend months working on. There's no conflict here, other than your attempts to change the subject to "prove" me wrong. Your attitude here is telling. You're complaining about the status of the documentation, but then refusing to read it, even when I tell you 4 times where it is. THAT is why you're having such a hard time with it. So... go read the docs on http://networkradius.com/doc/. Your questions are answered there. If they're not, wait a few months, and the site will be updated with more documentation. Either way, it's clear that the main problem here is that you're fanatically set against reading documentation and following instructions. Alan DeKok.
On 2015-04-14 20:28:49 +0000, Alan Buxey said:
But, really, why would you have needed >to start writing that site if what I'm saying isn't at least partially >true?
Sheesh. You moan about lack of documentation and yet you then moan about the fact that documentation is being written! Issues man. Issues.
I'm not moaning about it being written. I said it's looking good. You left out the bit that sentence is replying to: ``` No. I'm pointing out that *your* complaints aren't substantiated by the evidence. And that's why I started on the commercial documentation: http://networkradius.com/doc/ ``` Other than that, look back at the start of the thread. I ignored Alan DeKok until he chimed in in response to my statement about not seeing any documentation detailing whether or not the `modules` block can be used multiple times like the `client` block. He maintains the documentation in the default config file explains it, and I maintain that it doesn't. That's the whole conversation in a nutshell. I honestly don't care if this project produces better documentation or not. The animosity of DeKok's responses to people asking for assistance is not something I want to deal with. That's why I turned to this list as a last resort, using gmane as the gateway so I can just forget about it later, and why I ignored his initial reply in this thread. I don't know why I tried to help him understand why people ask the questions they do here; I knew it was a fools errand to begin with. Thank you to the two people who actually responded with real responses. I'm done with this thread (and hopefully this list).
so I can just forget about it later
(and later remark) Yep. Slurp slurp vampire. Ask for answers and requirements for yourself. Moan about lack of documentation for your own requirements and don't contribute to the ecosystem so that the next person along who wants to do something similar can't find any resources. The circle of life it seems. Alan
On Apr 14, 2015, at 4:46 PM, James Sumners <james.sumners@clayton.edu> wrote:
I'm not moaning about it being written. I said it's looking good. You left out the bit that sentence is replying to:
Your comments were largely negative. They have been all along. Perhaps that influences how people react to you.
Other than that, look back at the start of the thread. I ignored Alan DeKok until he chimed in in response to my statement about not seeing any documentation detailing whether or not the `modules` block can be used multiple times like the `client` block.
He maintains the documentation in the default config file explains it, and I maintain that it doesn't. That's the whole conversation in a nutshell.
See, that's it in a nutshell. I posted text from radiusd.conf which explains that. Instead of responding like an honest person say "gosh, you're right", you respond to someone *else's* message, and tell the same lie.
I honestly don't care if this project produces better documentation or not. The animosity of DeKok's responses to people asking for assistance is not something I want to deal with.
Yeah, 99% of my responses on this list are simple, clear, and helpful. But... I get annoyed at people who don't read the existing docs and then lie about it. This makes you sad.
That's why I turned to this list as a last resort, using gmane as the gateway so I can just forget about it later, and why I ignored his initial reply in this thread. I don't know why I tried to help him understand why people ask the questions they do here; I knew it was a fools errand to begin with.
I've seen your kind come and go. They make the same complaints, and then whine and run away. It's a script, TBH. And a tiring one.
Thank you to the two people who actually responded with real responses. I'm done with this thread (and hopefully this list).
This list is for people who want to solve problems, and people who are willing to learn. So I guess your exit makes sense. Alan DeKok.
On 14 Apr 2015, at 16:28, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
But, really, why would you have needed >to start writing that site if what I'm saying isn't at least partially >true?
Sheesh. You moan about lack of documentation and yet you then moan about the fact that documentation is being written! Issues man. Issues.
People complain about documentation, and, in some areas the server is lacking documentation, but for the majority of modules, and the server core, the inline documentation is complete. If a config item isn't documented, it's generally because it's intended for use by developers. Regarding the specific example in radiusd.conf there's some expectation that people attempting to use the server will be familiar in basic AAA concepts. Reading RFC 2865/2866 are a good place to start in understanding these concepts. That's what I did 8 years ago when I first started using the server. I learned what 802.1X was and how 802.1X worked by reading the IEEE 802.1X standard and RFC 3748, then how EAP and RADIUS were related by reading RFC 3579. In your case, if you read RFC 2865 and 2866 you'll understand what proxying means in this context. You can then make your own decisions about whether you'd want to turn it off. In general FreeRADIUS sticks pretty closely to the terms and functionality described in RFCs and IEEE standards. Once you have that foundation the server makes more sense. The commercially funded documentation is for those who don't want to spend the time amassing knowledge on AAA, or figuring out how the server works by working back from examples or descriptions of config items. The main reasons for writing it are: 1) It rounds out the project by providing documentation in a traditional format. 2) It encourages traffic over to networkradius.com, which hopefully leeds to more commercial projects. Commercial projects are how Alan and I can work on the server full time. Alan D has attempted to get more community involvement in the documentation effort, and some people have stepped up. Unfortunately those people have also resisted coordination (passively), and so the result has been patchy. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
1) I read the thread where someone was having an issue with rlm_memcached
* rlm_cache_memcached There's no rlm_memcached.
2) I tried to investigate this module as I could be interested in using it
https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/mods-avail... There's inline documentation for the *two* specific memcached options. For the first option, which specifies the server parameters there's a link to the memcached documentation which documents all the options that can be used. There's complete and comprehensive documentation for the rlm_cache module as a whole, in the config file. If you want some quick ideas on how to use rlm_cache there's a user contributed wiki page http://wiki.freeradius.org/modules/Rlm_cache -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 2015-04-14 17:47:26 +0000, Arran Cudbard-Bell said:
1) I read the thread where someone was having an issue with rlm_memcached
* rlm_cache_memcached
There's no rlm_memcached.
2) I tried to investigate this module as I could be interested in using it
https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/mods-avail...
There's inline documentation for the *two* specific memcached options.
For the first option, which specifies the server parameters there's a link to the memcached documentation which documents all the options that can be used.
There's complete and comprehensive documentation for the rlm_cache module as a whole, in the config file.
If you want some quick ideas on how to use rlm_cache there's a user contributed wiki page
http://wiki.freeradius.org/modules/Rlm_cache
-Arran
Thank you. I was looking for a config file with "memcached" in the name.
> On 14 Apr 2015, at 14:25, James Sumners <james.sumners@clayton.edu> wrote: > > On 2015-04-14 17:47:26 +0000, Arran Cudbard-Bell said: > >>> 1) I read the thread where someone was having an issue with rlm_memcached >> * rlm_cache_memcached >> There's no rlm_memcached. >>> 2) I tried to investigate this module as I could be interested in using it >> https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/mods-available/cache#L40 There's inline documentation for the *two* specific memcached options. >> For the first option, which specifies the server parameters there's a link to the memcached documentation which documents all the options that can be used. >> There's complete and comprehensive documentation for the rlm_cache module as a whole, in the config file. >> If you want some quick ideas on how to use rlm_cache there's a user contributed wiki page >> http://wiki.freeradius.org/modules/Rlm_cache >> -Arran > > > Thank you. I was looking for a config file with "memcached" in the name. It's a driver/sub-module. There's also rlm_cache_rbtree which uses an in memory red/black tree for cache entry indexing. sub-modules don't typically have separate configs, because they don't have sufficient options to justify it. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
James Sumners -
Phil Mayers