To give you an idea of how ACUA realizes these goals, consider a typical environment in which ACUA might be used: a university dial-up. This hypothetical dial-up has 32 modems attached to a Linux box through a Cyclades. The administrator of this dial-up has chosen to use ACUA to meet the following requirements.

Access Control Requirements

Enforcement of Time Limits

Time limits are not enforced unless all dial-up lines are in use. Because access to this hypothetical dial-up is free of charge, there is no point in denying access when there are free lines available. When all lines are busy, and a user has exceeded any one of the time limits on the system, the user is said to have "become an eligible victim." When a user is actually kicked off of the system, the user is said to be "victimized" by ACUA. When all dial-up lines are busy, and multiple "eligible victims" exist, a single victim will be decided upon as follows:

Daily Time Limit

Users of the dial-up are allowed 2 hours per day. Thus, a user who has been online for 2 hours in a given day will become an "eligible victim" whenever all dial-up lines are busy.

Idle Time Limit

If users leave their connection idle longer than 15 minutes, they will become eligible victims if all dial-up lines are busy.

Prime-Time Time Limit

The system is particularly busy between the hours of 7 p.m. and 10 p.m. In an effort to ensure that each user has a chance to get online during this busy period, a time limit unique to these hours is required. Each user will be allowed 1 hour of online time during these hours of heavy usage. For example, if a user connects to the system at 7 p.m. and uses it until 8 p.m., he or she will have used 1 hour of the 2-hour daily time limit, and all of the 1 hour prime-time limit. Since it is still prime-time (8 p.m.), the user will become an eligible victim if all lines are busy.

User Administration Requirements

Accounts that have not been used for a long time (e.g., 6 months) should be automatically removed from the system. This will prevent dead accounts from piling up, wasting disk space, and creating a security problem.

When an account is created on the system, it will be created in a deactivated state (no access permitted). The account can then be activated for a length of time, and automatically deactivated when this time has expired. For example, suppose a new student account is to be created. It will first be created in a deactivated state. The student will then be given a "subscription" that provides access to the dial-up for 4 months. After 4 months, the account will automatically be deactivated and could optionally be reactivated afterward. Deactivated accounts are unusable, so any account that remains deactivated for 6 months will be removed from the system automatically.

When users are prevented from logging in, they should be given a personalized message explaining why. When users are kicked off the system, they should be sent a personalized email explaining why. This way, users will not think that they are being denied access as a result of some sort of bug or problem.

ACUA Features

Access Control

ACUA can follow simple or complex rules that tell it when to disallow access to specific users. One of ACUA's programs is a daemon called user_updated that wakes up every minute and (among other things) deducts time for each user who is online and decides whether or not to kick any users off. The code that makes this assessment corresponds (roughly) to the following pseudocode:

for each user {
let t1 = time remaining for
limitation 1
let t2 = time remaining for
limitation 2
let t3 = time remaining for
limitation 3
.
.
.
let tn = time remaining for
limitation n
let t = min(t1, t2, t3, ..., tn)

if (t <= 0) then  /* this user
can be
kicked
off */
.
.
.
endif
}

Before I define what limitations can be enforced, I need to define the term "busy." The system is defined as "busy" when the number of idle dial-up lines is an administrator-defined threshold. The administrator may set the threshold at 0, meaning that the system is "busy" only when all dial-up lines are in use.

Idle Time

The administrator can define an idle timeout (e.g., 15 minutes). Users who leave their connection idle for longer than this may lose their connection. However, particular users may be allowed to leave their connections idle as long as the system is not busy. In general, users who are paying by the minute should be idled out unconditionally, and other users should be allowed to leave their connection idle provided the system is not busy.

Overall Time Limit

Time is sometimes sold in blocks. For example, users may purchase a subscription that entitles them to X minutes of usage. ACUA needs to keep track of how much time has been used and deny users access to the system when they have used their time. However, it may be desirable (especially in the case of BBSs and nonprofit dial-ups) to allow users who have used all of their time to remain online provided the system is not busy. If there is no monetary gain to be had, then there is absolutely no point in denying access - it is wasteful to do so.

Session Time Limit

A session time limit can be configured for each user - it is the number of minutes that a login session is permitted to last. The idea here is simply to provide fair access and prevent users from monopolizing access to phone lines. Usually, it does not make sense to enforce this time limit unless the system is busy.

Time Class Time Limit

ACUA allows the administrator to define "time classes." The default ACUA configuration file acua.config defines the following time classes:

time class 0: 24/7                               "all the time"
time class 1: 8am-6pm Mon-Fri        "business hours"
time class 2: 7pm-10pm Mon-Fri      "prime-time"
time class 3: all weekend                   "weekend"

Given these time classes, time limits specific to each time class can be defined for individual users. For example, it may be desirable to limit the amount of time that a user is allowed online during "prime-time" to one hour (as was done on the hypothetical university dial-up). This way, each user of the system should have a chance to get online and check mail, etc. during this busy period. Usually, it will not make sense to enforce such time limits unless the system is busy.

If a user has a negative time limit for a particular time class, special meanings apply:

-1: no limit for this time class

-2: no session time deducted during this time class

-3: no overall or session time deducted during this time class (a "free ride" during this time class). You might want to define a time class or two for very slow periods and set time class time limits of -3 for those time classes.

"SmartTime" Feature

This feature allows time to be deducted only when the system is busy, and it can apply to the overall, session, and time class time limits. The purpose of this feature is to guarantee a particular user a certain amount of time online during busy periods.

Data Transfer Limit

Overall or session limits on data sent, data received, and total data transferred may be imposed.

Busy Threshold and User Priorities

As I mentioned earlier, the administrator can define the threshold point at which ACUA considers the system to be busy. This threshold point can also play a role in determining how users get kicked off of the system. Let us define:

int
nKick(int busyThreshold, int nFreeLines) {
return max(0, busyThreshold - nFreeLines);
}

If the administrator chooses, when the system is busy user_updated will victimize nKick() users. Note that:

if nFreeLines >= busyThreshold, nKick = 0.

For example, suppose:

busyThreshold = 2
nFreeLines = 0 (all dial-up lines in use)

There are four users online who are out of time.

nKick(2, 0) = 2, so user_updated will kick two people off the system. The two users who were "spared" may or may not be able to stay online much longer - if the system becomes busy again, they may be at the top of the list of "eligible victims."

How does user_updated decide which users to kick off? First, it creates a list of "eligible victims" (users who have exceeded one or more of their time limits). If "MaxKick" is enabled, user_updated will sort this list of eligible victims in ascending order of the function victimCompare() and victimize only the first nKick() users in the sorted list (Listing 1).

As you may have surmised from looking at the pseudocode, ACUA allows a priority to be associated with each user. This priority setting will determine how they rank against other users when user_updated sorts eligible victims. On my hypothetical university dial-up, faculty were given a higher priority than students. So if ACUA had to decide between victimizing a faculty member and victimizing a student, it would always choose the student. Users with priority = 0 are treated as a special case - when the system is busy, they can be kicked off even if they have time left!

CPU priority can be determined based on ACUA priority. ACUA user priorities are in the range 0 to 7. On a Linux system, CPU priorities are in the range 19 to -20. If the administrator chooses, ACUA user priorities will be mapped to CPU priorities as shown in Table 1.

User Administration

Email Notification

When users accounts or subscriptions are due to expire soon, personalized email can be automatically sent to advise them of this fact. Also, whenever a user is kicked off the system, that user is sent a personalized email explaining why.

Account Expiration

When a user account is created, an expiration date for the account can be configured. When this date arrives, ACUA will automatically delete the account.

Subscriptions

A subscription is simply a temporary increase (or decrease) in access. When a user is given a subscription, an expiration date for the subscription is specified. When this date arrives, ACUA will automatically unsubscribe the account. Unsubscribing an account is simply a matter of restoring the account to the state it was in before the subscription was given. On the hypothetical university dial-up discussed before, student accounts were created in a deactivated state, then activated with a 4-month subscription.

Information Reporting

Account Status Information

A utility is provided that displays ACUA user records in a human-readable format (Table 2).

Statistical Information

ACUA collects information on system use. A tool is provided that dumps the collected data in a format appropriate for processing by a Perl script or importing into a spreadsheet. A Perl script is provided that computes and displays statistical information such as the example shown in Listing 2.

Report Generation

A tool is provided to dump ACUA user records in a format appropriate for processing by a Perl script, or importing into a spreadsheet. An example Perl script that generates a useful report is provided.

Miscellaneous Utility Programs

ACUA includes utilities called clean_proc and clean_tmp. As you may have guessed, clean_proc kills processes left behind by careless or malicious users. clean_tmp unlinks files under specified directories (usually /tmp or /var/tmp) that meet specific criteria (e.g., not owned by root, not accessed in the last week, etc.)

ACUA Scripts and Programs

A detailed discussion of ACUA's programs is not appropriate to this article - the manual pages provide that information. However, I think it is appropriate to provide a list of ACUA's programs with a brief description of what each one does (see Table 3).

Porting Efforts

ACUA has been ported to *BSD with very little difficulty, and I am very interested in porting it to as many popular UNIX flavors as possible. There is very little nonportable code in ACUA. Porting to another version UNIX is basically a matter of rewriting 100 or so lines of code. If you're interested in a port to a particular version of UNIX, please email me, and we'll work out an arrangement to get the port done.

ACUA Resources

Source and binary distributions of ACUA are available at:

ftp://sunsite.unc.edu/pub/Linux/system/serial

ACUA also has a home on the WWW now, thanks to Allen Bolderoff who is using ACUA at his ISP. The source and binary distributions, complete documentation, and ACUA mailing list archive are available at:

http://acua.gist.net.au
<text<

Conclusion

I have enjoyed working on ACUA, and I believe it has matured into a powerful and flexible package. Please let me know if you have any bug reports, ideas for improvements, or just want to tell me that ACUA is working great and making your life easier.

About the Author

Adam McKee received a B.Sc. Honours in Comp. Sci. from the University of Saskatchewan in 1996. He currently lives and works in Saskatoon, Sask. as a Programmer/Analyst. He can be reached at: amckee@poboxes.com.