What can be defined in sites-enable/a_site

[Alan DeKok]

On Apr 14, 2015, at 2:19 PM, James Sumners <james.sumners at 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.