7. Client Access Configuration (access.conf)
All authentication, accounting and user profiles must be configured in access.conf. NNTPSwich uses several kinds of configuration objects. Wildmats, Aliases, ACL's, Authenticators and Profiles. When a client connects, it's IP adress it mached against an ACL and assigned a profile accordingly. If a client authenticates, the username is matched against the Authenticator string and, if successfully authenticated, assigned the profile from the authenticator. Upon connecting a client its ip address is matched against an ACL. Based on this ACL, a Profile is assigned to the client. A profile contains among other things, configuration options like the maximum number of clients for that profile and patterns for group bases authentication.
If a client authenticates the username is looked up in one of the Authenticators. Based on the Authenticator two Aliases are applied to the authentication information from the client. One Alias specifies how to authenticate a client and one Alias specifies how to process accounting traffic for that user.
7.1. ACLs or IP Based Access Control
ACLs are configured in the access.conf file. The format is as follows:
CIDR/Address Options Profile
CIDR/Address defines the ip address or ip range in CIDR format. Examples are 127.0.0.1/32 or 192.168.1.0/24.
The Options are one of read, post, apost, unlimit, auth or deny. Read and post are pretty obvious. Apost specifies a client is allowed an Approved: header in hist posts. If apost is not specified the Approved: header is automatically stripped. Nolimit option specifies that the MaxConcurrent option from the Profile is not applied, the client can have as many connections as possible. When the auth keyword is specified it enforces client authentication. The client must authenticate before using privileged commands. Finally if deny is specified the client doesn't have any access at all.
The Profile keyword defines the name of the profile applied to the connecting client.
Always, at least the catch-all 0/0 address should be defined. Examples (choose only one of them):
acl CIDR/Address Options Profile acl 0/0 deny # deny everything (profile "default") acl 0/0 read,post,auth # force auth, read/post after auth (profile "default") acl 0/0 read local # read only profile "local"
7.2. Aliases
Aliases specify alternate names for utility library functions and its arguments. Aliases are specified in profiles.conf like:
alias name library.so arguments
Name is just a short name from which you can reference to within the Authenticators configuration. Library is one of the included authentication or accounting libraries. Depending on the library a different set of arguments is required. Examples include:
alias CustomerOne auth_passwd.so /etc/nntpswitch/passwd.customer alias RemoteAuth auth_remote.so news.news-service.com:119 alias AcctGeneric acct_syslog.so local4.info
Look for more examples at the descriptions of the different modules. See chapter Authorization-and-Accounting for details.
7.3. Authenticators
Authenticators are patterns which are matched to the username. Depending on the pattern an Alias for accounting and one for authorization can be specified. If the authentication succeeds the Profile is applied. All authenticators are specified in the file auth.conf.
auth pattern auth-alias acct-alias profile
Pattern isn't really a pattern. A pattern has to start with an asterix(*) or has to end with one. Examples:
auth *@example.com CustomerOne AcctGeneric ExampleCom auth chiparus!* AuthChiparus AcctChiparus ChiparusProfile auth * # auth_default acct_default default
Always leave the last line where the pattern is only an asterix. By default the aliases auth_default and acct_default are used with profile default.
7.4. Wildmats
Wildmats are just aliases for wildmat pattern so you can easily access them from the profile configuration. One pattern is matched for read access (the group() and list commands) and the other is matched for posting. If no wildmat names are used, the default is all, which matches *. Examples:
wildmat all * wildmat none !* wildmat nl nl.* wildmat comprec comp.*,rec.* wildmat nobin *,!*bin*
7.5. Profiles
Profiles takes care of configuring a client, or rather a user. There is only one special profile which is called default. The default profile must have all options configured to a reasonably default setting.
Patterns ReadPat and PostPat define the wildmat names of the patterns applied to the group the client is selecting.
The variables XComplaintsTo, Hostname, Organization, ForceOrganization and AddNNTPPostingHost are used for posting only. This way you can have different headers for different users.
The Banner and MaxConcurrent variables only work when a profile is applied to an ACL and have no use when applied to an Authenticator. If you set ReplaceBanner to 1 all the NNTPSwitch versioning stuff and group/connection counters aren't displayed.
MaxConnections is the maximum number of connections for a profile. When a client logs in initially a profile is selected from an ACL. If the client logs in the profile is switched to one from an Authenicator. Only one profile (the currently selected) keeps track of the MaxConnections. Also the MaxConnections from nntpswitch.conf is global while the one from a profile only applies to that profile.
Additionally the profile specifies the MaxSessionTime and MaxSessionBytes which speak for themselves.
7.6. Setting user and connection limits
There are two things to keep in mind. A Connection (or port, or slot) is a single TCP session to the server. A User is a set of slots from the same hostname, or - if the user is authenticated - the username.
MaxUsers and MaxConnections are limits for the complete profile. Setting MaxConnections to 500 and MaxUsers to 400 will start to disconnect users either when it reaches 500 connections, or if there are 400 different users connected. Normally MaxUsers it the tunable parameter, we don't really care about the MaxConnections so you could just set MaxConnections high in the default profile.
MaxHostConcurrent and MaxUserConcurrent can basically both be the same value. If you want to allow different users connecting from the same ip address you should make MaxHostConcurrent atleast N times MaxUserConcurrent.
Rate-limits can and must be configured on a user basis. It is not possible to limit single connections which doesn't make much sense anyway. Either set MaxUserMbit or MaxUserKbit which both initialize MaxUserBPS actually. Each user will have a bandwidth limit of this amount.
Rate-limits for the complete profile can be set with almost the same options. MaxProfileMbit, MaxProfileKbit or MarProfileBPS. Profile rate-limits will balance all the available bandwidth equally amongst all connections, not all users. So with profile rate-limits activated, users with more connections are faster than users with only 1 connection.
 | Important |
|---|---|
MaxUserBPS and MaxProfileBPS are in bytes per second and MaxUserMbit, MaxUserKbit, MaxProfileMbit and MaxProfileKbit are in bits per second. |