3 ## readers.conf - Access control and configuration for nnrpd
10 ## default: "<identity>"
11 ## default-domain: "<email-domain>"
14 ## users: "<userlist>"
15 ## newsgroups: "<newsgroups>"
21 ## Other parameters are possible. See readers.conf(5) for all the
22 ## details. Only one of newsgroups or read/post may be used in a single
25 ## If the connecting host is not matched by any hosts: parameter of any
26 ## auth group, it will be denied access. auth groups assign an identity
27 ## string to connections, access groups grant privileges to identity
28 ## strings matched by their users: parameters.
30 ## In all cases, the last match found is used, so put defaults first.
32 ## For a news server that allows connections from anyone within a
33 ## particular domain or IP address range, just uncomment the "local" auth
34 ## group and the "local" access group below and adjust the hosts: and
35 ## default: parameters of the auth group and the users: parameter of the
36 ## access group for your local network and domain name. That's all there
39 ## For more complicated configurations, read the comments on the examples
40 ## and also see the examples and explanations in readers.conf(5). The
41 ## examples in readers.conf(5) include setups that require the user to
42 ## log in with a username and password (the example in this file only
43 ## uses simple host-based authentication).
45 # The only groups enabled by default (the rest of this file is
46 # commented-out examples). This assigns the identity of <localhost> to
50 hosts: "localhost, 127.0.0.1, ipv6-localhost, ::1, stdin"
51 default: "<localhost>"
54 # Grant that specific identity access to read and post to any newsgroup.
62 # This auth group matches all connections from example.com or machines in
63 # the example.com domain and gives them the identity <local>@example.com.
64 # Instead of using wildmat patterns to match machine names, you could also
65 # put a wildmat pattern matching IP addresses or an IP range specified
66 # using CIDR notation (like 10.10.10.0/24) here.
69 # hosts: "*.example.com, example.com"
70 # default: "<local>@example.com"
73 # This auth group matches a subset of machines and assigns connections
74 # from there an identity of "<read>@example.com"; these systems should
75 # only have read access, no posting privileges.
78 # hosts: "*.newuser.example.com"
79 # default: "<read>@example.com"
82 # This auth group matches the systems at a guest institution that should
83 # be allowed to read the example.events.* hierarchy but nothing else.
86 # hosts: "*.example.org"
87 # default: "<events-only>@example.org"
90 # Finally, this auth group matches some particular systems which have been
91 # abusing the server. Note that it doesn't assign them an identity at
92 # all; the "empty" identity created in this fashion won't match any users:
93 # parameters. Note also that it's last, so anything matching this entry
94 # will take precedent over everything above it.
97 # hosts: "badguy-dsl.example.com, kiosk.public-access.example.com"
101 # Now for the access groups. All of our access groups should have users:
102 # parameters so there are no access groups that match connections without
103 # an identity (such as are generated by the "abusers" entry above).
104 # First, the default case of local users, who get to read and post to
108 # users: "<local>@example.com"
112 # Now, the read-only folks, who only get to read everything.
114 #access "read-only" {
115 # users: "<read>@example.com"
119 # Finally, the events-only people who get to read and post but only to a
120 # specific hierarchy.
122 #access "events-only" {
123 # users: "<events-only>@example.org"
124 # newsgroups: "example.events.*"