samples/readers.conf

   1 ##  $Id: readers.conf 4371 2001-01-16 15:35:38Z rra $
   2 ##
   3 ##  readers.conf - Access control and configuration for nnrpd
   4 ##
   5 ##  Format:
   6 ##      auth "<name>" {
   7 ##              hosts: "<hostlist>"
   8 ##              auth: "<authprog>"
   9 ##              res: "<resprog>"
  10 ##              default: "<identity>"
  11 ##              default-domain: "<email-domain>"
  12 ##      }
  13 ##      access "<name>" {
  14 ##              users: "<userlist>"
  15 ##              newsgroups: "<newsgroups>"
  16 ##              read: "<read>"
  17 ##              post: "<post>"
  18 ##              access: "<perm>"
  19 ##      }
  20 ##
  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
  23 ##  access group.
  24 ##
  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.
  29 ##
  30 ##  In all cases, the last match found is used, so put defaults first.
  31 ##
  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
  37 ##  is to it.
  38 ##
  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).
  44 ##
  45 ##  NOTE: Unlike in previous versions of INN, nnrpd will now refuse any
  46 ##  post from anyone to a moderated newsgroup that contains an Approved:
  47 ##  header unless their access block has an access: key containing the
  48 ##  "A" flag.  This is to prevent abuse of moderated groups, but it means
  49 ##  that if you support any newsgroup moderators, you need to make sure
  50 ##  to add such a line to the access group that affects them.  See the
  51 ##  access group for localhost below for an example.
  52
  53 # The only groups enabled by default (the rest of this file is
  54 # commented-out examples).  This assigns the identity of <localhost> to
  55 # the local machine
  56
  57 auth "localhost" {
  58     hosts: "localhost, 127.0.0.1, stdin"
  59     default: "<localhost>"
  60 }
  61
  62 # Grant that specific identity access to read and post to any newsgroup
  63 # and allow it to post articles with Approved: headers to moderated
  64 # groups.
  65
  66 access "localhost" {
  67     users: "<localhost>"
  68     newsgroups: "*"
  69     access: RPA
  70 }
  71
  72
  73 # This auth group matches all connections from example.com or machines in
  74 # the example.com domain and gives them the identity <local>@example.com.
  75 # Instead of using wildmat patterns to match machine names, you could also
  76 # put a wildmat pattern matching IP addresses or an IP range specified
  77 # using CIDR notation (like 10.10.10.0/24) here.
  78
  79 #auth "local" {
  80 #    hosts: "*.example.com, example.com"
  81 #    default: "<local>@example.com"
  82 #}
  83
  84 # This auth group matches a subset of machines and assigns connections
  85 # from there an identity of "<read>@example.com"; these systems should
  86 # only have read access, no posting privileges.
  87
  88 #auth "read-only" {
  89 #    hosts: "*.newuser.example.com"
  90 #    default: "<read>@example.com"
  91 #}
  92
  93 # This auth group matches the systems at a guest institution that should
  94 # be allowed to read the example.events.* hierarchy but nothing else.
  95
  96 #auth "events-only" {
  97 #    hosts: "*.example.org"
  98 #    default: "<events-only>@example.org"
  99 #}
 100
 101 # Finally, this auth group matches some particular systems which have been
 102 # abusing the server.  Note that it doesn't assign them an identity at
 103 # all; the "empty" identity created in this fashion won't match any users:
 104 # parameters.  Note also that it's last, so anything matching this entry
 105 # will take precedent over everything above it.
 106
 107 #auth "abusers" {
 108 #    hosts: "badguy-dsl.example.com, kiosk.public-access.example.com"
 109 #}
 110
 111
 112 # Now for the access groups.  All of our access groups should have users:
 113 # parameters so there are no access groups that match connections without
 114 # an identity (such as are generated by the "abusers" entry above).
 115 # First, the default case of local users, who get to read and post to
 116 # everything.
 117
 118 #access "local" {
 119 #    users: "<local>@example.com"
 120 #    newsgroups: "*"
 121 #}
 122
 123 # Now, the read-only folks, who only get to read everything.
 124
 125 #access "read-only" {
 126 #    users: "<read>@example.com"
 127 #    read: "*"
 128 #}
 129
 130 # Finally, the events-only people who get to read and post but only to a
 131 # specific hierarchy.
 132
 133 #access "events-only" {
 134 #    users: "<events-only>@example.org"
 135 #    newsgroups: "example.events.*"
 136 #}