##  readers.conf - Access control and configuration for nnrpd
##
##  Format:
##      auth "<name>" {
##          hosts: "<hostlist>"
##          auth: "<authprog>"
##          default: "<identity>"
##      }
##      access "<name>" {
##          users: "<userlist>"
##          newsgroups: "<newsgroups>"
##          access: "<perm>"
##          # Or instead of newsgroups/access:
##          read: "<read>"
##          post: "<post>"
##      }
##
##  Other parameters are possible.  See the examples below and readers.conf(5)
##  for all the details and more examples.  Only one of newsgroups or read/post
##  may be used in a single access group.
##
##  If the connecting host is not matched by any "hosts" parameter of any auth
##  group, it will be denied access.  auth groups assign an identity string to
##  connections, access groups grant privileges to identity strings matched by
##  their "users" parameters.
##
##  In all cases, the last match found is used, so put defaults first.
##
##  For a news server that allows connections from anyone within a particular
##  domain or IP address range, just uncomment the "local" auth group and the
##  "local" access group below and adjust the "hosts" and "default" parameters
##  of the auth group and the "users" parameter of the access group for your
##  local network.  That's all there is to do.
##
##  For more complicated configurations, read the comments on the examples and
##  lso see the examples and explanations in readers.conf(5).

# The only groups enabled by default (the rest of this file is commented-out
# examples).  This assigns the identity of <localhost> to the local machine.

auth "localhost" {
    hosts: "localhost, 127.0.0.1, ::1, stdin"
    default: "<localhost>"
}

# Grant that specific identity access to read and post to any newsgroup and
# allow it to post articles with Approved header fields to moderated groups.
# If several different posters are assigned this identity, or you have scripts
# that post external articles from different persons (via inews for instance),
# then no user-specific Cancel-Lock hashes should be generated for them
# (otherwise any person posting from localhost would be able to send an
# authenticated withdrawal of an article originally sent by another person also
# posting from localhost).

access "localhost" {
    users: "<localhost>"
    newsgroups: "*"
    access: RPA
    addcanlockuser: none
}

# This auth group matches all connections from example.com or machines in the
# example.com domain and gives them the identity "<local>".
# Instead of using wildmat patterns to match machine names, you could also put
# a wildmat pattern matching IP addresses or an IP range specified using CIDR
# notation (like 10.10.10.0/24) here.

#auth "local" {
#    hosts: "*.example.com, example.com"
#    default: "<local>"
#}

# This auth group matches a subset of machines and assigns connections from
# there an identity of "<read>"; these systems should only have read access,
# no posting privileges.  Deny the access to Bob's machine.

#auth "read-only" {
#    hosts: "*.newuser.example.com, !bob.newuser.example.com"
#    default: "<read>"
#}

# This auth group applies to all authenticated users against the passwords
# present in the /home/news/db/users file.  See the ckpasswd(8) documentation
# for how to set up this file.  You may also want to use "ckpasswd" without
# any argument, in which case PAM authentication is used (as already set in
# your system).
# Remember that auth groups are processed from the last one in this file to
# the first one (bottom up).  As soon as an auth group matches, the user is
# assigned the corresponding identity.  Besides, his identity may be different
# when he connects (he has not yet sent any authentication commands), and when
# he has authenticated himself.
# Authenticated users will be allowed to read the example.events.* hierarchy
# but nothing else.  They will be given their username as identity (for the
# "users" parameter in access groups).

#auth "events-only" {
#    hosts: "*"
#    auth: "ckpasswd -f /home/news/db/users"
#}

# Finally, this auth group matches some particular systems which have been
# abusing the server.  Note that it doesn't assign them an identity at
# all; the "empty" identity created in this fashion won't match any "users"
# parameters.  Note also that it's last, so anything matching this entry
# will take precedent over everything above it.

#auth "abusers" {
#    hosts: "badguy-dsl.example.com, kiosk.public-access.example.com"
#}

# Now for the access groups.  All of our access groups should have "users"
# parameters so there are no access groups that match connections without
# an identity (such as are generated by the "abusers" entry above).
# First, the default case of local users, who get to read and post to
# everything.  As they are not individually authenticated, no user-specific
# Cancel-Lock hashes should be generated for them.

#access "local" {
#    users: "<local>"
#    newsgroups: "*"
#    addcanlockuser: none
#}

# Now, the read-only folks, who only get to read everything.

#access "read-only" {
#    users: "<read>"
#    read: "*"
#}

# Finally, the events-only people who get to read and post but only to a
# specific hierarchy.
# Beware to exclude known identities that should not be given that access
# group (for instance <localhost> if you have a special auth group for it).
# The last access block matching the identity in this file is used.

#access "events-only" {
#    users: "*,!<localhost>"
#    newsgroups: "example.events.*"
#}
