readers.conf samples

[Brandon Hume]

> 	Maybe I'm not as smart as my mom tells me I am, but I'm
> having a hard time with readers.conf.

I've been trying to figure it out for quite a while now.  :)

I think I've finally got something I can use, though, after plowing through
the perm.c source tracking down bugs.

I was just trying to convert what I'd put in nnrp.access as:

*:: -no- : -no- :!*
stdin:R:::*
*.dal.ca:RP:::*,!alt.sex.bondage,!alt.sex
lab-*.dal.ca:R:::*,!alt.sex.bondage,!alt.sex

What I ended up with was:

auth "STDIN" {
	hosts:		"stdin"
	default:	"<full-access>"
}

auth "GENERAL" {
	hosts:		"*.dal.ca"
	default:	"<general-access>"
}

auth "LABS" {
	hosts:		"lab-*.dal.ca"
	default:	"<lab-access>"
}

access "FULL" {
	users:		"<full-access>"
	newsgroups:	"*"
	access:		"Read Post"
}

access "GENERAL" {
	users:		"<general-access>"
	newsgroups:	"*,!alt.sex.bondage,!alt.sex"
	access:		"Read Post"
}

access "LABS" {
	users:		"<lab-access>"
	newsgroups:	"*,!alt.sex.bondage,!alt.sex"
	access:		"Read"
}


... this seems to emulate the nnrp.access behavior I was looking for.  I've
probably done things in a manner the people with real knowledge would 
consider unnecessary.

Some noteworthy (to me) things I ran across while putting this together:

    - The wildmat pattern is case sensitive.  The connecting hostname is
lowercased before pattern matching, but the pattern itself is not.  So if I
put "*.Dal.Ca" as my host: pattern, even though this is the manner in which it
is actually nameserved, the hostname will be lowercased and fail to match.
INN 2.2.x doesn't appear to be like this.
    - The default: in the auth realms is what links it to the "user" in the
access realms.  I don't think this is true in all cases, though, and I haven't
gone into the "key" keyword yet (I was intent on "MAKE IT GO!" at the time).
    - Since I've used "host:" in every auth realm above, if, when a host 
connects, non-matching authentication realms will be thrown away WHILE nnrpd
parses the readers.conf.  With the current perm.c source, when the parser
returns, if not a single host pattern matched, I'll end up with an empty
auth_realms array, which nnrpd doesn't check for, and nnrpd will segfault
and die.

Any and all of the items above may result from misfiring synapses on my part.


A question of my own to the rest of the inn-workers... is anybody still 
working on the readers.conf code?  I've had the segfaulting-nnrpd problem for
a while, and I can't find any mention of further work on the readers.conf
code in the mailing list archives since August.  I've made changes in today's
snapshot which cures the segfaults, at least for me, should I bother sending
in a diff?

A lot of perm.c just seems unfinished... with what looks to me potential
memory leaks and the like.  But I may be reading the code wrong, and I don't
want to make assumptions.

-- 
Brandon Hume    - hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/
                       -> Solaris Snob and general NOCMonkey