Subscriptions

Subscriptions control access to various resources and services. NetIDs are permitted to services, either implicitly or explicitly. Once permitted, the subscription to the service can be activated. At some point the permit to the service is revoked whereupon the subscription expires and becomes deactivated.

Categories and Permits

Each NetID has a collection of categories associated with it and each of the categories has a status of current, grace or former. For example, all enrolled undergraduate students will have a category 1 category record. Category 1 is, appropriately enough, UW Undergraduate Student. When students graduate, after seven or eight years, their category 1 record will be given a grace status. Eventually they will fall out of Grace state, usually on the 10th day of the 2nd quarter following their departure, and the category record's status will become former.

In addition to the standard categories like Student, Staff and Faculty, there are ad hoc categories such as the C&C Staff and MyUW.net Paid categories that are assigned and revoked through external processes.

Permits to services are based on the category records associated with a NetID. Implicit permits apply to all NetIDs of a particular category and explicit permits apply to specific NetIDs. An example of an implicit permit would be all staff and faculty having access to the Homer cluster. An example of an explicit permit would be an instructor's TA having access to the Homer cluster to allow updating the course web site for a quarter.

The implicit permits tend to stick around forever. People will lose their current category status and their subscription will expire, but the generic permit will remain. The explicit permits are usually set to expire after a given date or when the sponsor of the permit is no longer valid.

In addition to permits, there are also anti-permits or deny records that override other permits to services if they exist. One example of an implicit deny record was designed to force clinicians to use the Aagaard cluster instead of Homer. All clinicians were permitted to Aagaard and denied to Homer. Thus they could not create a Homer cluster account even if they were also staff members. The idea of being a member of a class causing you to have reduced privileges never goes over very well, though, and that implicit deny was dropped shortly after it was implemented. One implicit deny still in effect is that all NetIDs are permitted to create secret questions and then Temporary NetIDs are denied that privilege. Explicit deny records, while being more practical, are also seldom if ever used. Usually only when someone has been bad.

Permits are also based on the status of the category record. Most permits are based on the NetID's category being in current state, but some are based on a category in the former state. The grace state ends up being a fuzzy area that affords the user both the benefits of being current and being former. For example, Current Undergraduate Students can subscribe to Dante accounts. Former Undergraduate Students can sign up for a MyUW.net account. Students who are in the Grace state can subscribe to both of these services. This allows them to transfer their files over before they expire.

When the status of a NetID changes, e.g., the owner graduates and becomes a former student, some of the active subscriptions will lose their permits. Unless there's another permit for that service for that NetID, the subscription will expire and be deactivated.

Actions

There are nine separate actions that can be performed on a subscription:

0. Status
   The Status function requests information about the current status of the subscription.
    
1. Activate
   Permitted subscriptions can be activated by the owner of the NetID or the administrator of the service.
    
2. Deactivate
   Subscriptions can be deactivated by the owner of the NetID or the administrator of the service. Subscriptions that are no longer permitted will be deactivated by the expiration process.
    
3. Suspend
   The suspend action serves no useful purpose. It was originally intended to allow the owner of a NetID to do something with subscriptions that was not well thought out.
    
4. Resume
   The resume action undoes the suspend action. Resume, which does get invoked, should do the same thing as the activate action.
    
5. Modify
   The modify action is used to change a parameter associated with a subscription. Each subscription can have a 255 character data field for service specific information. For example, the u-forwarding service stores the forwarding email address in the data field.
    
6. Setname
   When a NetID changes, the setname action is used to notify the various service providers of the name change.
    
7. Disuser
   The disuser action is performed by the service administrator to disable a subscription in such a way that the owner of the NetID cannot re-enable it.
    
8. Reuser
   The reuser action undoes the disuser action and is only accessible by the administrator of the service.
    

These actions are performed by various tools that need to manipulate subscriptions. Most notable is the Manage tool that is found at the URL:

https://uwnetid.washington.edu/manage/

https://uwnetid.washington.edu/manid/

The Subscribe Script

When an action is performed on a subscription, a script is invoked on the Mango server to perform the action. This script runs various commands depending on which action it is performing and which service is involved.

Actions on most of the UA account related services are performed by the Subman Subscription Manager. Actions on subscriptions for other services are handled in their own special way and it's completely up to the subscribe script to decide what to do and how to do it.

The source for the subscribe script is found in Tulsa as:

/tulsa/tfx/subman-daemon/DEFAULT/usr/local/lib/shuksan/subscribe

The script begins by classifying each subscription code into one of 10 types. Each type of subscription and how it is handled is then delegated to the following people or subgroups:

Type 1:	Standard pwsync service	ken@u
Type 2:	Other frame/subman service	ken@u
Type 3:	Unused, old quota graph trickery	ken@u
Type 4:	Email forwarding subscriptions	imf@u
Type 5:	MyUW	imf@u
Type 6:	Labs subscriptions	iti-cp@u
Type 7:	Unused/Free for reuse	whoever@wherever
Type 8:	Webfile services	jprosser@u
Type 9:	Sleeper to debug time-out problems	adhoc
Type X:	Other -- Unsupported	iti-cp@u

Each subsection of the script looks something like:

#
#  Type 8: Webfile service  (jprosser@u)
#

    T8)
        case $MODE in
          PRODUCTION)
            echo "$CODE $ACTION $MGO_UWNETID $ADMIN" |
            /usr/local/lib/ufile/manage 2>> /usr/local/lib/ufile/debug_log
            RC=$?
            case $RC in
              100)  exit 20;;           # Successful Activation
              101)  exit 0;;            # Failed
              102)  exit 23;;           # Pending
              103)  exit 24;;           # Deleted
              104)  exit 21;;           # Expired
              105)  exit 22;;           # Disuser
              106)  exit 29;;           # Suspend
              107)  exit $MGO_SUBSTATUS;;       # No changes
                *)  cat <<EOF
$WEB_ERR
We received an unexpected response code of $RC.  There was probably
some sort of internal error.  Please try again.  If the problem
persists, you should contact us at ${WEB_I}help@u.washington.edu${WEB_NOI}
or 206-543-5970.
$WEB_END
EOF
                    exit 0;;
            esac 
            ;;

          #
          #  MODE not PRODUCTION
          #

          *)
            cat <<EOF
$WEB_ALERT
Sorry, we don't do anything for this subscription in evaluation mode.
$WEB_END
EOF
            exit 0
            ;;
        esac
        ;;

The PRODUCTION portion of the script gets installed on the production Mango servers while the %else clause gets installed on the evaluation Mango servers. What actually happens when the evaluation mode protion of the script is invoked is up to the delegate for the subscription type. For example, the Type 1 pwsync service subscriptions do some parameter syntax checking and say "Yeah, okay, did it" rather than exiting with a failure state.

The exit status of the script dictates the final subscription record's status as commented above. A status code of 24 is special in that the subscription record is actually deleted from the Shuksan database.