Giant Sponsors Database Historical Documentation Page (Pruned)

Working from SponsorsDataAccountsDocumentationBig as a start, we attempt to indicate sections which are irrelevant and annotate others.

equipment database (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance.

sponsors database

An understanding of the old sponsors "database" would be relevant to anyone trying to understand, or create, replacements of it.

Name:

     sponsors - the accounts-master package's sponsor database

Synopsis:

Description:

     The  sponsors  database  is  typically  stored  in a several
     files, one per sponsor,  in  several  directories,  one  per
     department.

     Blank lines, and those beginning with a are ignored.

     Lines  ending with a backslash, are considered to be contin-
     ued on the following line as if it were  part  of  the  same
     line.  (Ensure that the backslash really is the last charac-
     ter on the line and is not followed by a space.)

     In most cases the backslash isn't  required,  as  lines  may
     also  be  continued by indenting the continuation lines with
     tabs or spaces.

     Lines beginning with an equal sign  separate  sections.   By
     convention, eight equal signs (i.e. are used before each new
     billcode or class, and  four  equal  signs  (i.e.  are  used
     before each resource.

     Each  line  comprises  a  keyword, immediately followed by a
     colon, and a list of space-separated arguments.  Lists  must
     never  be  empty.  If a particular keyword does not apply or
     its value is unknown, the line should be  omitted  (or  com-
     mented out with a and not left with an empty list.

     If the first character of a list is a character, the rest of
     the line will be the name of a decommentable file  (relative
     to the current file if the first character of the name isn't
     The line will then behave as if the list were  the  contents
     of  that  file.   In  general this feature shouldn't be used
     except where necessary to automate  the  processing  of  the
     Registrar's data.

Structure:

     The  data  is  stored  in  a logical hierarchy, each sponsor
     being divided into several  billcodes,  each  billcode  into
     several  classes,  and  each  class  into several resources.
     Each billcode is assumed to  belong  to  the  most  recently
     encountered  sponsor,  and resets all information associated
     with any previously encountered billcodes.   Each  class  is
     assumed to belong to the most recently encountered billcode,
     and resets all information associated  with  any  previously
     encountered  classes.  Each resource is assumed to belong to
     the  most  recently  encountered  class,  and   resets   all
     information   associated  with  any  previously  encountered
     resource.

     Values for each keyword are accumulated until an keyword  is
     encountered,  at which point all accumulated data is applied
     to the userids named on that line.

Sponsor Section:

     This describes the person sponsoring everything that follows
     to the end of the file.

     Sponsor: Name of person

     Department: Sponsor's UW department, if any

     Address: Sponsor's paper mailing address, if any
          Multiple lines may be used if required.

     Email: Sponsor's e-mail address, if any

     Billing: NoCharge
          Sponsor is not charged for sponsored resources.

     Billing: Automatic
          Charges  are  automatically debited to sponsor's Finan-
          cial Services account.

     Statements: NoPaper
          A paper statement is not mailed  to  the  sponsor  each
          month.

     Statements: NoWeb
          The  sponsor's  monthly  statement is not posted in our
          web space.

     Infrastructure: FirstConnection

     Userids: userid:idnumber list
          Multiple lines  may  be  used  if  required.   See  the
          Resource subsubsubsection for details about the Userids
          list.

Billcode SubSection:

     This defines the University billing code to which  all  fol-
     lowing  classes, up to the end of the file or the next bill-
     code, will be charged.  If  a  University  billcode  is  not
     appropriate  (e.g.  resources  for internal use), some other
     string may be used.  Check with the accountING package main-
     tainer to see what is or is not appropriate.

     Billcode: UW billcode or equivalent

Class SubSubSection:

     This defines the the class to which all following resources,
     up to the end of the file or the  next  class  or  billcode,
     will be charged.

     Class names must be unique (i.e. no class may have more than
     one sponsor).  The reports produced by list_sponsors(8) will
     begin on a new page for each class.

     Class: Name of class
          There  are  currently  no rules about what a class name
          may be, but for the moment, to be consistent  with  the
          old  software,  they should be of the form where is one
          through five alphabetic characters,  is  three  digits,
          and is zero or one alphabetic characters.

          To  avoid  confusion  with  those classes automatically
          generated from the Registrar's  data,  one  should  use
          Dual-Case when creating new class names (e.g. Soft100).

     Description: Description of class
          A short description of the purpose of the class.

     Usage: Primary use of the class
          One of or The most significant value  is  as  it  means
          that  usage  under  this  class should not count toward
          active usage on a machine.  (e.g. for  a  staff  member
          that must occasionally sign onto a researcher's machine
          to maintain (but not use) its software.).

     Subsidy: Dean's subsidy
          or indicating whether or not the Dean's subsidy applies
          to  resources  sponsored  by  this class (by default it
          does).

     Instructors: Name of professor, class instructor(s), et al.
          The human(s) responsible for the class.

     Enrollment: Number of members
          The estimated size of the class.

     Load: low, moderate, high, or heavy
          The estimated cpu load for the class.

     Requirements: Extra requirements
          A short list of extra requirements (e.g. special  soft-
          ware) for the class.

     Fee: Lab fee
          The  lab  fee charge for one term.  Can be given as the
          number of cents, or suffixed with or The  two  keywords
          may be abbreviated by truncation.

     MembershipStarts: Date to start
          Any  following  membership lists will be ignored before
          this date.

     MembershipEnds: Date to end
          Any following membership lists will  be  ignored  after
          this  date.  If a start date is given, the end date may
          be expressed relatively (e.g.

     Members:
          A list of userids that belong to this class.  Note that
          they  will not automatically be assigned any resources;
          that must be done by giving a value to an trigger.

Resource SubSubSubSection:

     This defines a set of resources to be billed to the  current
     class  under  the  current billcode for the current sponsor.
     The first line must select a resource:

     Computing: List of host names
          This defines resources  for  computer  accounts  to  be
          billed  to the current class under the current billcode
          for the current sponsor.

     Printing: List of printer queue names
          This defines printer access to be billed to the current
          class  under the current billcode for the current spon-
          sor.

     MailAlias: mail-alias
          This defines a mail alias (e.g.  to be  billed  to  the
          current  class  under the current billcode for the cur-
          rent sponsor.  If the mail-alias is more than 7 charac-
          ters  long,  it  must  also  include square brackets to
          indicate allowable userid truncation.
          (e.g.  generates 5 aliases,
          but generates only one alias).

     PPP: List of PPP names
          This defines PPP access to be  billed  to  the  current
          class  under the current billcode for the current spon-
          sor.

     Any following lines define the  attributes  associated  with
     the resource, which is allocated whenever a

     AssignTo: List of userids

     line  is encountered.  More than one line may be given for a
     resource, typically either to avoid long lines or to apply a
     start or end date to some but not all users.

     The  special  userid  means  all  userids defined in members
     lists for this class.

     For the mailalias resource, the given  userids  may  contain
     at-signs,  and  other punctuation, including colons, and are
     not checked for validity.

     Otherwise, each userid should be immediately followed by  an
     optional  the redundancy providing checking for incorrect or
     misspelled userids.  In addition, if the userid (and id num-
     ber)  is  on  a machine not in the standard userid namespace
     (e.g. for accessing our printers), it should be followed  by
     indicating  the  name  of  another machine where the account
     resides.

     To avoid entering the id number each time  the  same  userid
     appears  for  the same sponsor, the id number may be omitted
     without generating any warnings if the userid and id  number
     are given in the list in the Sponsor section.

     If a

     IgnoreUserids: List of userids

     is  in effect when a userid list is encountered, any entries
     common to both lists will be ignored.   (This  is  currently
     implemented only for the resource.

     The following attributes are common to most resources.

     Quota: Restrictions on the amount of the resource
          For  PPP accounts it is not defined, for printers it is
          a money limit (format is as described in the  field  in
          the  subsubsection above), and for computer accounts it
          restricts the amount of  disk  space.   Disk  space  is
          assumed  to  be  in kilobytes, but may be suffixed with
          with or to indicate kilobytes, megabytes, or gigabytes.
          To  specify  a  quota  without limit, the abbreviatable
          keyword may be used.

     SponsorshipStarts: Date sponsorship takes effect
          This is a date before  which  the  sponsorship  of  the
          resource does not apply.

     SponsorshipEnds: Date sponsorship ends
          This  is  a  date  after  which  the sponsorship of the
          resource no longer applies.  If a start date is  given,
          the  end  date  may  be expressed relatively (e.g.  End
          dates are used, rather than simply deleting  the  data,
          because  the sponsorship information may be required by
          the accountING software for several  months  after  the
          resources  are no longer needed.  For the PPP resource,
          the end date may instead be given  as  the  name  of  a
          host.  In that case, the sponsorship of the resource is
          considered to have ended when the user no longer has an
          account on the specified host.

     Address: IP-Address
          This applies only to the PPP resource.  This causes the
          resource to be assigned this fixed  IP  address  rather
          than being assigned one arbitrarily each time a connec-
          tion is made.

     Groups: Group membership
          This applies only to the computing resource, and  lists
          unix groups of which the user should be a member.

     Hosts: List of hosts
          This  applies only to the mailalias resource, and lists
          unix regions on which the alias should apply.

     Account: Sponsoring account
          This applies only to the printing resource.  If  speci-
          fied,  the  single  account  name  that  will  be  used
          (instead of the class name) as the field in the printer
          quota  database.   (i.e. the value the must be supplied
          when using

          Note that this means that these account  names  are  in
          the  same namespace as class names, and therefore along
          with the class names should be unique.

Second Attempt At A Descripton:

     The following is meant to represent the  tree  structure  of
     the database.

        Each file contains one sponsor:

        Sponsor:
        Department:
        Address:
        Email:
        Userids:

        ======== Each sponsor is divided into one or more billcodes:

        Billcode1      ...      Billcode      ...      BillcodeN

        ======== Each billcode is divided into one or more classes:

            Class1        ...      Class        ...      ClassN
            Description1           Description           DescriptionN

        ==== Each class is divided into one or more resources:

        Computing...  Printing...  MailAlias...  PPP1...
        Starts        Starts       Starts        Starts
        Ends          Ends         Ends          Ends
        Quota         Quota        Hosts         Address
        Groups        Account

        Each resource is divided into one or more lists of userids:

              AssignTo1   ...   AssignTo2   ...   AssignToN

     Each sponsor, billcode, class, or resource section overrides
     all attributes defined by  previous  sections  of  the  same
     type.

     Whenever  an  AssignTo  list  is  found  for a resource, all
     attributes accumulated so far are assigned to each userid in
     the list.

     It  is  important  to  understand the difference between how
     values are accumulated as described in the previous two sen-
     tences.   The  Userid  list  does *not* reset any previously
     defined values for the current resource.  So  for  instance,
     if the file contained the sequence:

        ...
        Computing: math watdragon
        Quota: 100M

        AssignTo: *MEMBERS*

        SponsorshipStarts: 1996/01/01
        SponsorshipEnds: +1Year
        AssignTo: jdoe jsmith

        SponsorshipStarts: 1996/06/06
        AssignTo: fbaggins gabandabalf

     The  fbaggins account would also inherit the 100M quota and,
     perhaps more surprisingly, the January 1997 end date.

Files Used:

See Also:

     get_all_sponsors(3w), list_sponsors(8).

Copyright:

     Copyright (C) 1995,2006, MFCF, University of Waterloo.

list_equipment (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance.

accounts-master package

An understanding of the old sponsors "database" would be relevant to anyone trying to understand, or create, replacements of it. The accounts-master package was where a typical sponsors "database" would be housed.

Name:

     accounts-master-package, accounts-master - description of
     the accounts-master package

Description:

     The accounts-master package allows one to manage distributed
     resources from a single centralized database.  It currently
     knows about printer quotas, PPP access, and UNIX accounts.

     The central database contains a description of who sponsors
     what resources.  The software determines what each resource
     provider should provide, passes this information to the
     resource providers, and tells them "make it so".

     The database also provides information for billing and
     accounting purposes, while the control files associated with
     individual resources provide information about why a user
     has the resources.

Sponsors Database:

     The database (described in sponsors(5)) consists of text
     files in an arbitrary structure under the "data/sponsors"
     directory.  A simple text editor (e.g.  vi(1)) provides the
     user interface, though if desired one could design a more
     elaborate mechanism.

     The sponsor_resources(8) program examines the database and
     produces a number of text files under the three directories
     "data/resources/{account,ppp,printer}".

     Each file under a resource directory bears the name of one
     of the resource providers (e.g.  "account/logos.math",
     "ppp/anik3.mfcf", "printer/ps_mfcf").

Sponsored Resources:

     The accounts-client(8) program distributes these resource
     files to each resource provider and does the appropriate
     things to make the resources correspond to the contents of
     the file.

     In the case of UNIX accounts, this means running the spon-
     sor_accounts(8) program on the machine of interest.  On each
     machine, a file, "/software/accounts/data/users", contains
     sponsor-related information for each entry in the
     "/etc/passwd" file.

     The program ignores accounts not created by the sponsors
     data, and adjusts the resources of all sponsored accounts to
     match the new resource data.  This involves changing disk
     quotas and the "/etc/passwd" and "/etc/group" files.  It
     does not actually remove entries from the passwd file, but
     instead simply marks them as expired, other jobs later
     making them unusable (expire_accounts(8)) and finally remov-
     ing them and their files (rmallusr(8)).

Sponsor Reports:

     The list_sponsors(8) program produces summaries of sponsored
     resources suitable for sending to the individual sponsors.
     Each report begins a new page for each class (a set of com-
     mon resources), showing the specific allocation of resources
     for each user.

Bugs:

     Currently, the sponsors data does not affect /etc/group.

     Currently, nothing uses the printer and ppp resource infor-
     mation.

     This package contains many other files and programs.

See Also:

     sponsors(5).

Copyright:

     Copyright (C) 1997, MFCF, University of Waterloo.

accounts-client command (VERY IMPORTANT)

accounts-client (and sponsor_resources ) were the programs/commands old maintainers of the old sponsors "database" would use most often (in many cases almost exclusively) to put changes they configured into production.

Name:

     accounts-client - updates accounts on remote clients

Synopsis:

     accounts-client [[host=]hostname]

Description:

     accounts-client uses the data compiled by the accounts-mas-
     ter(8) program ("/software/accounts-mas-
     ter/data/resources/*/*") and updates all accounts-controlled
     accounts on the specified "host=" host.

     If no explicit host is given, all hosts (i.e. those listed
     by `hostin group=mfcf_sponsored`, `hostin group=mfcf_ads`,
     `hostin group=mfcf_macs`, `hostin group=windows-masters`,
     and `hostin group=polaris-masters`) are updated.  (Replace
     "_mfcf" with "_cscf" or other appropriate administration.)

     For each of the "mfcf_sponsored" machines (the most common
     case), the account resource file is distributed to the
     machine and the sponsor_accounts(8) program is run on that
     machine to do the update.

     Processing for the other types of hosts is handled in a sim-
     ilar way, though the host where the update processing occurs
     might not be the same as the target host.

Note:

     Unlike accounts-master(8), this program does not detach
     itself, and so killing it might have some effect on the
     remote updates.

Example:

     When updating all clients, one would typically do something
     like this:
          math% accounts-client >&~/#ac
          math% cut -c1-79 ~/#ac | page

     For a single client, math% accounts-client student.math
     would be used.

See Also:

     accounts-master(8), sponsor_resources(8), do_polaris(8),
     sponsor_accounts(8), mfcf-course-accounts(i).

Copyright:

     Copyright (C) 1996, 1997, 2009, MFCF, University of Water-
     loo.

accounts-master command (Reasonably Important)

accounts-master is the command everyone forgot about. But, arguably, every time they ran sponsor_resources they should have been running accounts-master instead. accounts-master did a superset of sponsor_resources and the running of sponsor_resources alone was a sort of optimization in most situations. But an astonishing number of people were surprised to hear about the function of accounts-master. Perhaps that was partly because it tended to be run automatically once a day.

Apparently missing here is a man page for make_all_accounts which does the actual work

Name:

     accounts-master - gathers current information for maintain-
     ing accounts

Synopsis:

     accounts-master [{+|-}Verbose]

Description:

     accounts-master gathers information from various places and
     produces lists of accounts and resources that should exist
     on the machines it administers.  In addition, (some) printer
     quotas, man pages and web pages are updated.

     The program, accounts-client(8), should then be used to
     update the accounts on those machines (hostin group=stu-
     dents).

     The output, which is appended to the log file, is much more
     detailed than one would normally want to see, so unless one
     specifies "+Verbose", all blank lines and all lines begin-
     ning with "+++" are omitted from the output.  If one doesn't
     want to see the progress of the job as it proceeds, specify-
     ing "-Verbose" will suppress all lines beginning with "===",
     and in theory only the important messages (e.g. errors) will
     be displayed.

     Note that the real work is done by a program that is submit-
     ted by an rsh where it runs in the background independent of
     this program.  That means that one may kill the accounts-
     master program without affecting the actual update.

Bugs:

     This is still somewhat under development.

     What is actually considered to be important output isn't
     always correct.

     The output sometimes contains lines of the form "ADD1: ...".
     This indicates something I have to update by hand, but even-
     tually it will be automated.  The same list will appear
     every time, so you don't need to worry about telling me
     about them.

Files Used:

     /software/accounts-master/data/sponsors/
     /software/accounts-master/data/resources/
     /software/accounts/logs/accounts-master

See Also:

     accounts-client(8), sponsor_resources(8), mfcf-course-
     accounts(i).

Copyright:

     Copyright (C) 1994,1996, MFCF, University of Waterloo.

check_equipment command (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance.

check_network command (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance. Even if check_network had applications apart from the equipment database, CSCF never made use of the command.

get_printer_quotas command

Name:

     get_printer_quotas - merge requests for accounts

Synopsis:

     get_printer_quotas

Description:

     get_printer_quotas uses the "Printers" control file to
     determine the current printer quota allocations, and to pro-
     duce batch update files suitable for each printer.

     At the moment nothing beyond this is automated.  One must do
     the following by hand:

          math% get_printer_quotas
          math% cd /software/accounts-master/data/work
          math% lpquota_update_sucks -p ps_mfcf - < lpquotas.update.ps_mfcf
          math% lpquota_update_sucks -p [ ... ] - < lpquotas.update.[ ... ]
          math% mv lpquotas.new lpquotas

     making sure that each step works successfully.  The program
     will fail harmlessly if the file "lpquotas.new" exists.

     The very first time, the "lpquotas" file, which contains the
     current values of the printer quotas, must be created as an
     empty file.

     At the end of each term the following must be done, before
     switching to the Registrar's data for the next term.

     - Remove all non-cumulative entries from the Printers file.
     - Update as usual.
     - Zap the lpquotas file (to forget about everything).
     - Set up the Printers file for the new term.
     - Switch all the other accounts things for the new term.
     - Do all other accounts updates for the new term.
     - Update as ususal.

Files:

     /software/accounts-master/data/control/Printers
     /software/accounts-master/data/work/lpquotas
     /software/accounts-master/data/work/lpquotas.new
     /software/accounts-master/data/work/lpquotas.update.<printer>

See Also:

     lpquota_update_sucks(8),

Copyright:

     Copyright (C) 1992, MFCF, University of Waterloo.

get_student_registry command (OBSOLETE)

This command is probably a predecessor of download_accounts_data. (Used by accounts_master ).

Name:

     get_student_registry - fetch the current student registry
     from Data Processing

Synopsis:

     get_student_registry

Description:

     get_student_registry fetches the current student registry
     data provided by Data Processing.  The file contains the
     following colon-separated fields:
     - family name
     - given name(s)
     - initials
     - id number
     - faculty
     - program
     - year and term
     - degree type
     - courses (separated by commas)

Files

     /software/accounts-master/data/temp/student_registry

See Also:

     register_student_programs(8).

Copyright:

     Copyright (C) 1991, MFCF, University of Waterloo.

get_userid_status command

Name:

     get_userid_status - gather the userid statuses in our admin-
     istration

Synopsis:

     servers/get_userid_status host*

Example:

     set hosts=`include_files config/hosts_mail | decomment`
     get_userid_status `cat $hosts`  >addresses

Description:

     get_userid_status runs userid_status(8) on each host given
     on the command line filling in any known id numbers to pro-
     duce the mail address for each id.

     Output consists of one line per userid in the form
     "userid:id:host:status", where "id" is the student,
     employee, or other id number associated with the userid, and
     "status" is one of: "Active", "Zmail", "Sendmail",
     "Expired", "Unused", "DelForward", "Deleted", or "Unknown",
     as described in mail_registry(8).

Note:

     This program is normally run only by the register_mail(8)
     program to produce input for the mail_registry(8) program.

See Also:

     userid_status(8), mail_registry(8), register_mail(8).

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

inuse command

This used to be a superset of some sort over just querying WatIAM (or equivalent). It would keep track of userids used privately across campus to avoid further conflicts beyond just WatIAM.

Name:

     inuse - query IST's inuse userid database

Synopsis:

     inuse [grep arguments]

Description:

     inuse searches the database of inuse userids maintained by
     IST.

     Typically one would use this to see if an about-to-be-ass-
     signed userid is in use anywhere on campus.

     Userids can be in full or truncated-to-8 format.  For short
     userids one would likely want to check for that userid
     exactly (e.g.  "jsmith" shouldn't match "ajsmith" or
     "jsmithjones"), using the -w grep option.

          % inuse -w jsmith

     For long userids one would likely want to check for both
     forms:

          % inuse -w 'rbutterw\|rbutterworth'

          % inuse '\\\<rbutterw'

          % inuse -w 'rbutte.\*'

     Each line of output contains three fields: Date, Userid,
     Host, and Source, where the Source is an occasionally mean-
     ingful comment supplied by the program that registers the
     userid as being in use, and the Date is the most recent date
     that the information in the other three fields was received
     (unfortunately they don't record the earliest such date
     too).

Notes:

     The right number of backslashes to use isn't always obvious.

     This uses a lot of cpu on one of IST's machines, so don't
     abuse it.

Commands Used:

     /software/gnu/bin/grep -E

Copyright:

     Copyright (C) 1998, MFCF, University of Waterloo.

list_classes command

Name:

     list_classes - list MFCF-resource classes

Synopsis:

     list_classes [-Registration] [+Noresources] [+Colons]
          [Sponsors=/software/accounts-master/data/sponsors/REGISTRAR]
          [[fields=]ALL|Cents|Printer|Class|Kbytes|
                    |Host|Limit|Enrollment|Load|Instructor|Com-
          ment]*

Options:

     [Sponsors=/software/accounts-master/data/sponsors/REGISTRAR]
          Directory (or file) containing class sponsorship infor-
          mation.

     [+Noresources]
          List "nowhere" classes too (i.e. those used only for
          generating .classlists).

     [-Registration]
          Don't list faculty and department pseudo-classes (e.g.
          cs08, arts3).

     [+Colons]
          Display output as colon-separated fields.

     [[fields=]fieldname]*
          Each specified field (which may be abbreviated by non-
          ambiguous truncation) is displayed in the output in the
          order given.  "ALL" implies all fields.

Description:

     list_classes Sorts, culls, and lists the Registrar sponsored
     classes in what is intended to be a more readable format.
     Future options might include "Host=hostname" to select by
     host.

Examples:

          list_classes class enrollment load instructor comment \
               >/software/mfcf-specific/man/mani/mfcf-classes.i
          list_classes cents printer class kbytes host instructor +reg \
               >/software/mfcf-specific/mani/mfcf-class-resources.i

See Also:

     sponsors5

Copyright:

     Copyright (C) 1993,1997,2001, MFCF, University of Waterloo.

list_sponsors command

Name:

     list_sponsors - list resource sponsors

Synopsis:

     list_sponsors [HaveExpired=121] [WillEnd=183]
     [[sponsorpath=]/software/accounts-master/data/sponsors]*
     [Resources=ALL|Printing|MailAliases|PPP|Computing|Equip-
     ment|Users|Sponsors|Classes]
     [Severity=Warnings|Notes|Errors]
     [ListNames=Classes|Resources|Users|Sponsors]

Examples:

     Put report into "#ls-stdout" and errors into "#ls-stderr":
     % ( list_sponsors > #ls-stdout )  >&#ls-stderr
     List accounts sponsored by MFCF:
     % cd /software/accounts-master/data/sponsors && list_spon-
     sors +s MFCF

Options:

     [[sponsorpath=]/software/accounts-master/data/sponsors]*
          Files (or directories to be recursively descended) con-
          taining the sponsor data.

     [HaveExpired=121]
          Warn about entries that expired more than this many
          days ago.

     [WillEnd=183]
          Warn about entries that will expire in fewer than this
          many days.

ment|Users|Sponsors|Classes]
     [Resources=ALL|Printing|MailAliases|PPP|Computing|Equip-
          Restrict the report to a specific section.  Note that
          "Users" isn't really a resource.

     [Severity=Warnings|Notes|Errors]
          Omit problem reports that are less than this severity.
          The default is warnings and errors, with notes sup-
          pressed.

     [ListNames=Classes|Resources|Users|Sponsors]
          Special purpose formatted output (still under deveop-
          ment).

Description:

     list_sponsors formats the contents of the sponsors database
     into reports (or summaries) suitable for sending to the
     sponsors.

     If all you are interested in is checking the database for
     problems, use the "ListNames=users" option to minimize the
     time it takes and the size of the standard output produced.

Standard Output:

     For the "ListNames=users" form, a simple list containing all
     "userid@host" and "userid@@host" forms defined by the
     database is produced.  This is handy for comparing the
     database against which accounts are actually on each
     machine.  The double "@" indicates that the host is one that
     doesn't claim to use standard userids.

     The normal form of the output comprises one report for each
     sponsor, each beginning on a new page with the sponsor's
     name, address, etc.  followed by listings of the computer
     accounts and printer accounts they sponsor, followed by a
     list of all sponsored userids containing their names, id
     numbers, etc.

     Sponsors should check that the resources for each account
     are correct, and that the userids they have requested really
     do correspond to the people described in the last section.

Error Output:

     Stderr may contain three classes of messages, one per line,
     prefixed with "Note:", "Warning:", or "Error:".  Notes are
     unimportant things that can be fixed when the presence of
     these messages becomes annoying enough.  Warnings are impor-
     tant things that the program managed to correct, but which
     should be fixed as soon as possible.  Errors are serious
     problems that cause the program to exit prematurely, and
     which must be corrected.

     The most common messages you are likely to see are:

     "Error: unknown host"
          The host isn't reachable from this machine.

     "Error: userid xxx should be yyy"
          An obsolete userid was given for the user.

     "Error: userid xxx has id number yyy not zzz"
          The userid and id number don't match.

     "Error: userid xxx is not a standard userid"
          The userid isn't registered as a standard userid.

     "Error: disk quota xxx begins with a non-digit"

     "Warning: we don't administer host xxx"
          The host isn't in our adminstration, so we don't create
          accounts there.

     "Warning: userid xxx should have id number zzz"
          No id number was given with the userid, but one should
          be given so that the redundancy will help check for
          typos and other mistakes.  This will eventually become
          a fatal error.

     "Warning: ignoring group xxx"
          A group such as "users" or "none" was assigned to the
          account, but such groups are automatically given any-
          way.

     "Warning: xxx requires exactly one argument"
          A non-essential information field was given bad data.

     "Note: sponsor xxx, billcode yyy, has expired account zzz"
          The entry expired before the time indicated by the
          "HaveExpired=" option.

     "Note: userid xxx should possibly be yyy"
          An obsolete standard userid has been given, but it's on
          a host that doesn't claim to have standard userids, so
          it might actually be a different user.

     "Note: userid xxx should possibly have id number zzz"
          If this is a standard userid, it should have the given
          id number, but it's on a host that doesn't claim to
          have standard userids, so it might actually be a dif-
          ferent user.

     "Note: userid xxx is a non-standard userid"
          The userid is non-standard, but it's on a host that
          doesn't claim to have standard userids.

Files:

     /software/accounts-master/data/sponsors/*/*

Copyright:

     Copyright (C) 1993, 1994, MFCF, University of Waterloo.

mail_deletion command

Name:

     mail_deletion - gather invalid uwdir mail addresses

Synopsis:

     servers/mail_deletion <host-file Outputdirectory=path
          Registered=registered-file Status=status-file

Description:

     mail_deletion reads a list of uwdir mail addresses (from
     Registered=) and compares them to a list of known addresses
     (from Status=), as produced by get_userid_status(8), and
     writes the result to a file in the Outputdirectory:
     "uwdir_wrong".

     Registered addresses with hosts that are not named in the
     host-file are ignored.

     The "uwdir_wrong" file is suitable (with a little editing)
     for passing to uwdir-submit(8).

Note:

     This program is normally run only by the register_mail(8)
     program.

See Also:

     get_userid_status(8), userid_status(8), uwdir-submit(8).

Copyright:

     Copyright (C) 1995,2010 MFCF, University of Waterloo.

mail_registry command

Name:

     mail_registry - gather mail addresses suitable for uwdir

Synopsis:

     servers/mail_registry [Domain=uwaterloo.ca]

Description:

     mail_registry reads a list of mail addresses as produced by
     the get_userid_status(8) program, reformats it
     ("id:address:status"), and writes the result to standard
     output.

     The first field of the output is an valid e-mail address
     with a fully-qualified host-domain-name.

     The second field is one of the following statuses:

     Active
          - /etc/passwd:  the account has been assigned a pass-
          word.

     Zmail
          "/software/zmailer/data/config/lists"

     Sendmail
          "/var/adm/sendmail/aliases"

     Expired
          "/software/accounts/data/users" - the account is living
          on borrowed time and unless circumstances change will
          become

     DelForward
          "/etc/passwd" - login shell is "/etc/Deleting*", but
          the home directory contains a ".forward" file.

     Unused
          "/etc/passwd" - encrypted password is "New-User*".
          i.e. the account has not yet been assigned a password.

     Deleted
          "/etc/passwd" - login shell is "/etc/Deleting*".  i.e.
          the account is unusable and will be removed at the end
          of the month.

     Unknown
          - should never happen.

     Records with the "Deleted" status are not written.

     If a userid has the same status on two hosts, the status for
     the host that was given first on the command line will be
     used.

     If a userid has different statuses on two hosts, the status
     that appears first in the above list will be used.  Note
     that the order of the above statuses is not the same as the
     priority used on the individual hosts by userid_status(8).

Note:

     This program is normally run only by the register_mail(8)
     program.

See Also:

     get_userid_status(8), userid_status(8), uwdir-submit(8).

Copyright:

     Copyright (C) 1995,2010, MFCF, University of Waterloo.

make_remote_accounts command (IMPORTANT)

Details in this page, however, are severely out-of-date. Details in this page, however, are severely out-of-date. Now it primarily exectutes, remotely, on the appropriate regional server, _sponsor_aliases_ and _sponsor_accounts_ (and different cases for special cases, such as Active Directory masters).

Name:

     make_remote_accounts - makes remote accounts.

Synopsis:

     servers/make_remote_accounts [-h hostname]

Description:

     This should not be called by anyone or anything other than
     by the accounts-client(8) program.

     make_remote_accounts Takes the information produced by
     make_all_accounts(8), and sends it to the specified machine
     (or all machines in `hostin group=students`), and then runs
     mkstuds(8) remotely to update the accounts.

Files Used:

     /software/accounts-master/data/control/{Classes,Special},
     /software/accounts-master/data/work/*.

Bugs:

     Can only handle userids that have student id numbers.

See Also:

     accounts-master(8), accounts-client(8), make-all-
     accounts(8), mfcf-course-accounts(i), mkstuds(8).

Copyright:

     Copyright (C) 1994, MFCF, University of Waterloo.

merge_account_requests command (OBSOLETE)

This has been superseded by something.

Name:

     merge_account_requests - merge requests for accounts

Synopsis:

     sort requests  merge_account_requests

Description:

     merge_account_requests fetches requests for accounts from
     standard input (which must be sorted by id number) and
     merges them with the student registry data.  The output con-
     tains the following colon-separated fields:
     - id number
     - initials
     - family name
     - given name(s)
     - courses (separated by commas)

Files:

     /software/accounts-master/data/temp/student_registry_mfcf

See Also:

     register_userids(8), get_special(8), get_student_reg-
     istry(8).

Copyright:

     Copyright (C) 1991, MFCF, University of Waterloo.

net_update_sql command

Name:

     net_update_sql - produce SQL commands to update inventory
     database SNMP info

Synopsis:

     servers/net_update_sql [Input=]/software/accounts-mas-
     ter/data/networks/NetInfo

Description:

     net_update_sql examines the ping and SNMP data compiled by
     network scanning and produces SQL commands to update the
     inventory database.

See Also:

     scan_network(8), check_network(8), update_network(8).

Copyright:

     Copyright (C) 2008 MFCF, University of Waterloo.

register_mail command

Name:

     register_mail - send preferred mail addresses to uwdir

Synopsis:

     servers/register_mail

Description:

     register_mail examines the mail address for all userids in
     the administration (actually the hosts named in the file
     "/software/accounts-master/config/hosts_mail" less those
     named in the file ".../config/hosts_nomail"), and sends them
     to the uwdir database.

     Because of the way quwdir(1) works, changes cannot be made
     to existing addresses.  Instead two updates are sent.

     The first update contains records for invalid mail addresses
     (no such userid on the machine, or the account is about to
     be deleted and has no ".forward" file), requesting that the
     entries be deleted.

     The second contains records for all userids in the adminis-
     tration.  Only those entries matching uwdir mail addresses
     that are empty will be filled in.

See Also:

     get_userid_status(8), userid_status(8), mail_deletion(8),
     mail_registry(8), quwdir(1).

Copyright:

     Copyright (C) 1995,2008 MFCF, University of Waterloo.

register_student_programs command (OBSOLETE)

This has been superseded by something.

Name:

     register_student_programs - merge requests for accounts

Synopsis:

     register_student_programs <input >output

Description:

     register_student_programs fetches requests for accounts from
     standard input (which are in the computing services format
     (see get_student_registry(8))) and produces records with the
     following colon-separated fields:
     - id number
     - initials
     - family name
     - given name(s)
     - courses (separated by commas)

     An additional item is added to the courses list of the form
     "faculty#", where "faculty" is the faculty the student is
     registered in, and "#" is the year the student is registered
     in, with "6" indicating a Masters student, "7" indicating a
     Doctors student, and "0" indicating a non-degree student or
     other unknown program.

Files:

     /software/accounts-master/data/temp/student_registry,
     /software/accounts-master/data/temp/student_registry_mfcf.

See Also:

     register_userids(8), get_special(8), get_student_reg-
     istry(8).

Copyright:

     Copyright (C) 1991, MFCF, University of Waterloo.

scan_network command (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance.

select_classes command

Name:

     select_classes - select classes of users for account cre-
     ation

Synopsis:

     select_classes

Description:

     select_classes reads account requests from its standard
     input and selects those that match entries in the Classes
     file.

Files:

     /software/accounts-master/data/host/Classes

See Also:

     make_account_requests(8).

Copyright:

     Copyright (C) 1991, MFCF, University of Waterloo.

sponsor_resources command (VERY IMPORTANT)

sponsor_resources (and accounts-client ) were the programs/commands old maintainers of the old sponsors "database" would use most often (in many cases almost exclusively) to put changes they configured into production.

Name:

     sponsor_resources - generate resource data from sponsors
     data

     'Warning: This is still under development."

Synopsis:

     sponsor_resources Severity=Warnings|Notes|Errors
     [sponsors=]/software/accounts-master/data/sponsors
     Configdirectory=/software/accounts-master/data/sponsors/.Config
     Resources=/software/accounts-master/data/resources
     Expired=90
     Today=today

Options:

     [sponsors=]/software/accounts-master/data/sponsors
          Directories or files containing the sponsors database.

     Configdirectory=/software/accounts-master/data/spon-
          sors/.Config
          Directory containing configuration files.

     Resources=/software/accounts-master/data/resources
          Directory to contain the sponsored resources output.

     Severity=Warnings|Notes|Errors
          Omit problem reports that are less than this severity.
          The default is warnings and errors, with notes sup-
          pressed.

     Expired=90
          Warn about sponsorship which ended more than the given
          number of days before the current time.

     Today=today
          Change the assumed date (time) used for all time-based
          calculations such as SponsorshipEnds.  The format "21
          Jan 2009" is accepted, as are various other date for-
          mats.

Description:

     sponsor_resources takes the sponsors data and sorts it by
     resource-type (account, printer, ppp) and by resource-
     provider (hostname, printername, anikname), and merges com-
     mon resources for each userid.

     The output is put into a number of files and directories.
     Each resource-type has an output directory, and each
     resource-provider has a file containing the resources it
     should provide.  For instance, the file "/software/accounts-
     master/data/resources/computing/math" will contain all the
     sponsored accounts that should be on the host "math".
     The output contains one line for each resource for each
     userid, with each field separated by colons.  The first
     field is always the userid.

     The accounts records then have fields for personal-name, id
     number, and preferred uid.

     The final field is a comma-separated list of resource quo-
     tas.  These are of the form: "Class-name(quotas)", where in
     the case of printers, the quotas are in pages; in ppps, the
     quotas are nonexistent; and in the case of accounts, the
     quotas are in kilobytes and may be followed by a semicolon
     and a comma-separated list of groups.

Files:

     /software/accounts-master/data/sponsors/*/*
     /software/accounts-master/data/resources/{account,printer,ppp}/*

See Also:

     accounts-master(8) - calls sponsor_resources and even more
     accounts-client(8) - update remote accounts
     list_sponsors(8) - explanation of error messages

Copyright:

     Copyright (C) 1996, 1997, MFCF, University of Waterloo.

update_network command (PRUNED)

The equipment database has been moved to the new inventory database. Any old documentation relating to the equipment database has no relevance.

update_web_pages command

Name:

     update_web_pages - update mfcf web pages with mfcf.math data

Synopsis:

     update_web_pages

Options:

     none

Description:

     update_web_pages is normally run from the crontab, but can
     be run safely at any time.

     It is intended to solve some of the problems caused by hav-
     ing the authoritative source for some information on
     "mfcf.math", while the MFCF web server is on "www.math", a
     different machine.

     The program is a script that simply calls other programs
     that produce automated web pages, and then distributes the
     results to the MFCF web space.

See Also:

     webify_owner_groups(8)

Copyright:

     Copyright (C) 2001, MFCF, University of Waterloo.

webify_owner_groups command

Name:

     webify_owner_groups - produce supported host web pages from
     Owners data

Synopsis:

     servers/webify_owner_groups
     [outputDirectory=/software/accounts-master/data/work/web-
     ify_owner_groups]
     [GroupDescriptions=/software/accounts-master/data/own-
     ers/.Config/groups]
     [[ownerpath=]/software/accounts-master/data/owners]

Options:

     outputDirectory=
          Directory where the html files are to be dumped

     GroupDescriptions=
          File containing host group descriptions.

     [ownerpath=]
          File or directory containing owner information.

Description:

     webify_owner_groups takes the hosts in the owners database
     (ownerpath=), and produces a web page for each group
     (including configured group descriptions (GroupDescrip-
     tions=)), and an "index.html" file therefor.

     All output is put into the specified directory (outputDirec-
     tory=).  The program will exit with a fatal error if it
     attempts to overwrite any existing file, so be sure to empty
     the directory before calling it.

     This program is intended to be run by another program (nor-
     mally from the crontab), which then distributes the new web
     pages to "www.math".

     The options are provided mostly for debugging purposes, and
     are not normally needed.

Files:

     /software/accounts-master/data/work/webify_owner_groups/*
     /software/accounts-master/data/owners/.Config/groups
     /software/accounts-master/data/owners/*
     check_owners(8)

Copyright:

     Copyright (C) 2001, MFCF, University of Waterloo.

diskquota command (OBSOLETE)

Eventually things changed so the vendor quota command would work.

Name:

     diskquota - show disk quota

Synopsis:

     diskquota [-Remote] [userid|uid]*

Description:

     The diskquota command shows the calling or specified user's
     disk quota on the current host and on all hosts from which
     writable filesystems are remotely mounted.  The -Remote flag
     will prevent any remote filesystems from being checked.

     If disk usage exceeds the user's soft limit, the hard limit
     is also displayed (in square brackets).

     On most machines, each user's disk quota and usage is nor-
     mally public information, available for any other user to
     see.  On machines where this policy isn't followed, users in
     group "operator" or "accounts" may query anyone's quota,
     even if the filesystem's quota file does not have general
     read permissions.

     If it checks any filesystems whose disk usage is in the pro-
     cess of being reinitialized (e.g. the Network Appliances
     fileservers for the student and general regions) this com-
     mand will exit with status 1.

See Also:

     quota(1)

Files Used:

     /software/accounts/config/regional/fashosts
     /software/accounts/config/regional/rquotahosts

Copyright:

     Copyright (C) 1993,2003,2005,2008 MFCF, University of Water-
     loo.

groups command (BEWARE)

Some people did not like the sometime tendency of xhier to provide locally enhanced versions of standard commands.

NAME

     groups - show group memberships

SYNOPSIS

     groups [-s<sep>] [-p] [user]
     groups [-s<sep>] [-p] -{g|G} group_name
     groups [-s<sep>] [-p] -{g|G} group_id

DESCRIPTION

     The groups command shows the groups to which you or the
     optionally specified user belong.

     If the -p flag is used, only the principal group for users
     is listed; in other words, only /etc/passwd is examined.  If
     -p is used, a group or userid must be specified.

     If the -g flag is used, all members of the specified group
     are shown.  (The group may be specified either by its name
     or numeric group id.)

     If the -G flag is used, only the user names of accounts for
     which the specified group is the principal group are listed;
     in other words, only /etc/passwd is examined.  The -G flag
     is obsolete - use -p -g instead.

     The string given as argument to the -s flag is used as the
     separator between the user names or group names listed,
     instead of a newline (the default for the -g/-G form) or a
     space (the default for the other form).  The string is
     parsed for escape sequences of the form "\x" where x is in
     the set {a, b, f, n, r, t, v}: these are mapped to
     corresponding ASCII character codes as per K&R 2nd ed. sec-
     tion 2.3.

     Each user belongs to a group specified in the password file
     /etc/passwd and possibly to other groups as specified in the
     file /etc/group.  If you do not own a file but belong to the
     group which it is owned by then you are granted group access
     to the file.

     When a new file is created it is given the group of the con-
     taining directory.

SEE ALSO

     setgroups(2)

FILES

     /etc/passwd, /etc/group

BUGS

     More groups should be allowed.
     groups in.

UW DIFFERENCES

     The -g, -G, -p, and -s options are UW enhancements.

init_home command (Somewhat Important)

This is probably less important than rmallusr. Standard Ubuntu Linux provides means to create home directories, e.g. on first login. Creating is easy. Removing the directories later, at an appropriate time, to recover disk space, is harder.

Name:

     init_home - reinitialize your home directory

Synopsis:

     init_home [userid]*

Description:

     This command tries to set up your home directory as it would
     be if the account had just been created.

     Usually this just means giving you the latest versions of
     the standard .cshrc and .profile files.  Any conflicting
     files will be renamed and a warning displayed.

     The optional userid arguments may only be given if you are
     root.

     If no userid is given, the directory specified by the
     "$HOME" environment variable will be used.  If that variable
     is not set, the home directory field in your "/etc/passwd"
     entry will be used.

     If your reason for using this command is that your ".cshrc"
     file is so messed up that you can't even execute any com-
     mands, you will have to invoke the command using its full
     pathname: /software/accounts/bin/init_home.

     Note that this command does not affect X11 files, such as
     ".xsession", which can be reinitialized by simply removing
     or renaming them and logging in again.

Configuration:

     Files and directories are copied, following symlinks, from
     the package's "init_home" configuration directories.

     It is a common practice for administrators to have accounts
     automatically created on all hosts that they are responsible
     for.  Such users can be listed as "userid@homehost" in the
     "admin/common_users" configuration file.  init_home will
     initialize the ".forward" and ".rhosts" files for these
     accounts (but will not replace existing instances thereof).

Files Used:

     /software/accounts/config/*/init_home
     /software/accounts/config/admin/common_users

See Also:

     .cshrc(5)

Copyright:

     Copyright (C) 1990, 1997, 2005, 2006, MFCF, University of
     Waterloo.

lastlog command (PRUNED)

laston command (PRUNED)

password command

This was suspiciously close to a local cover for standard vendor commands.

Name:

     password - change a user's password

Synopsis:

     password  Userid_Or_Idnumber
     password  Userid_Or_IdNumber  +Randompassword
     password  Userid_Or_IdNumber  Encryptedpassword=string

Description:

     This command enables certain non-super-users to change a
     user's password, though it is also handy for super-users,
     and can be used by non-privileged users to set their own
     passwords (in particular if they forget the spelling of
     "passwd").

     For students, it is best to give this command the 8-digit
     "id number", since it isn't possible to know their official
     userid from the information given on id cards (e.g. jsmith
     vs. j2smith).

     This mapping from id number to userid is likely to work only
     on machines that have MFCF standard userids.  Userid matches
     are performed before id-number matches, so administrations
     may use the payment[sic] field of the "users" file for some-
     thing other than the id-number without worrying about incor-
     rect matches.  (See users(5)).

     The "+Randompassword" option will generate a random password
     and ask if that is what you want it set to.

     The "Encryptedpassword=string" option will set the
     /etc/passwd entry to the given string.  Only a super user
     can set the string to be a single "*".  Don't try it unless
     you know what you're doing.

     New accounts are usually created with an illegal encrypted
     password, typically something like "New-User-S96".  (Illegal
     means anything that isn't exactly 13 characters chosen from
     the set of digits, letters, and the characters "/" and ".".)
     Some accounts may have illegal passwords simply because they
     are not intended ever to be logged into.  In such cases the
     illegal password entry should begin with the character "*".

     Someone in group "operator", "opcons", or "staff" may change
     passwords only on accounts that have an illegal encrypted
     value, providing the first character is not a "*".  Someone
     in group "accounts" may change any password provided that
     the encrypted form is not a single "*".

     No one but the super-user may change a vendor-supplied
     account (e.g.  "root" or "daemon"), as defined by the file
     "/software/setpw/config/arch/vendor.passwd".

See Also:

     passwd(1)

Copyright:

     Copyright (C) 1989, 1998, MFCF, University of Waterloo.

courses file (INTERESTING HISTORY)

This probably predates the current sponsors data set of files. The current sponsors data set of files was designed by admininstrative assistant Christie Gillin.

Name:

     Courses - accounts database of student courses

Synopsis:

     /software/regtape/data/Courses
     /software/accounts/data/host/Courses

Description:

     The file /software/regtape/data/Courses contains information
     describing the courses for which student accounts are to be
     created.  The file is maintained on the central regtape
     host, and distributed elsewhere to
     /software/accounts/data/host/Courses.

     The file consists of a series of records, one per line.
     Anything after '#' is treated as a comment and ignored, as
     are blank lines.  Fields are separated by blanks or tabs and
     are aligned only for human readability.

Example:

          #
          #course    host           kbytes   # Comments
          #

          # Modelling With Ordinary Differential Equations
          am250      crocus         500      # Marshman
          am250      dahlia         500      # Marshman
          am250      trillium       500      # Marshman

          # Modelling with Systems of Ordinary Diffiqueues
          am251      crocus         500      # Marshman
          am251      dahlia         500      # Marshman
          am251      trillium       500      # Marshman

Files:

     /software/regtape/data/Courses
     /software/accounts/data/host/Courses

Copyright:

     Copyright (c) 1990, MFCF, University of Waterloo.

fashosts file

Name:

     fashosts - declare remote fileserver information

Synopsis:

     /software/accounts/config/regional/fashosts

Description:

     The file /software/accounts/config/regional/fashosts lists
     the remote quota trees which are maintained remotely on ded-
     icated fileservers.  Blank lines, and any line whose first
     non-blank character is a "#" are ignored.

     Each line consists of the hostname of a remote fileserver
     (typically a faserver), optionally followed by a colon, and
     a list of one or more quota tree names, separated by commas.

Examples:

     The following lines might be used to declare remote filesys-
     tems on remote fileserver "hooke.math".  The first line
     assumes defaults will be used, while successive lines spec-
     ify more details of quota tree(s) explicitly.

          hooke.math
          hooke.math:vol1
          hooke.math:vol1/home
          hooke.math:vol1/home,vol1/mail

     Assuming that a user with a uid of 123 in the "/etc/passwd"
     file has a sponsored disk quota value of 5000 kbytes in the
     "data/users" file, the last line in the above example would
     produce these two lines in the fileserver's "/etc/quotas"
     file:

          123 user@/vol/vol1/home 5000K
          123 user@/vol/vol1/mail 5000K

Bugs:

     Until the parser can be made smarter, the "vol1/" values
     must be identical for all entries on a line.

     More significantly, each hostname must be different.

     Together these restrictions imply that each host can have
     only one "/vol1" value.

Development:

     Perhaps the syntax could be extended to allow the quotas on
     multiple qtrees to be different, with relative percentages
     or absolute amounts.  e.g.:

          hooke.math:vol1/home,vol1/mail(50%),vol1/scratch(20G)

See Also:

     mkquota(8)

Copyright:

     Copyright (C) 2008, MFCF,CSCF, University of Waterloo.

users file (VERY IMPORTANT)

/software/accounts/data/users aka /.software/regional/accounts/data/users was how appropriate user resource information got from the accounts master to the regional master, and from the regional master to its clients (where needed). (For example the userinfo command was basically a query of /software/accounts/data/users .

Name:

     users - user account related information

Synopsis:

     /software/accounts/data/users

Description:

     The file /software/accounts/data/users contains information
     about user accounts, complementing the /etc/passwd file,
     with which there should be a one-to-one mapping.

     The file consists of a series of records, one per line.
     Fields within a record are separated by a colon.  For his-
     torical reasons, the fields are called: "name", "quota",
     "date", "type", "payment", and "info".

     name contains the full untruncated userid of the user.

     quota
          contains the disk quota associated with the account.
          If not suffixed with "K", "k", "m", "M", "g", or "G",
          the value is considered to be in kilobytes.  [It is
          possible that this value may be followed by a comma and
          other quota values (e.g. monthly credit limit for
          printer pages or resource dollars), but such values are
          not currently set or used by any software in the
          accounts or accounts_client packages.]

     date the date the account was created in "yyyy/mm/dd" for-
          mat.  [historically, some other date formats were used]

     type [potentially] determines what controls the existence of
          this account.  If the field is "vendor" or "xhier", the
          account is vendor-sponsored or xhier-sponsored, as
          determined by /software/setpw/config/arch/vendor.passwd
          and /software/*/export/passwd.  If the first eight
          characters of the field are "sponsor-", the account is
          controlled by the sponsor_accounts(8) program in the
          accounts_client package.

          The vendor and xhier entries are automatically set by
          the accounts package's Install script, while other
          sponsored entries are maintained by accounts_client(8)
          updates.

          This sponsor method is the only one still used by MFCF.

          If the first two characters are apparently meaningless,
          and the rest of the field is "student", the account is
          controlled by the mkmerge(8) program in the accounts
          package, via calls from the make_remote_accounts(8)
          program in the accounts-master package.  If the field
          contains anything else, the account is not affected by
          either of these two accounts maintenance mechanisms.

     payment
          contains the id number of the owner of the account, if
          controlled by the sponsor or student mechanisms.  For
          sponsored accounts, this may be followed by the name of
          the user within parentheses.

     info For student accounts, this contains the classes in
          which the user is enrolled, in the form: "Name-Number-
          Term-dd/mm/yy".  For sponsored accounts, this contains
          the sponsoring classes, in the form:
          "class(quota[;group[,group]...])yyyy/mm/dd".  In both
          cases, the date is when the account was registered into
          that class on the host machine.  For xhier accounts,
          this field contains the names of the sponsoring xhier
          packages.

Files:

     /software/acccounts/data/users

See Also:

Bugs:

Copyright:

     Copyright (C) 1991,1996,2005, MFCF, University of Waterloo.

accounts package configuration

This must contains errors because of obsolete details.

Name:

     accounts-config - configuring the accounts package

Description:

     The accounts package can be configured to suit various
     administrations and individual hosts.  Some of those config-
     urations are described below.

Mail (old method):

     Questions and requests regarding user's accounts and
     resources are traditionally mailed to the userid "accounts".
     The home directory of the "accounts" account has a ".for-
     ward" file that redirects the mail to the mail alias
     "admin_accounts", which is controled by the package's admin-
     istration file "export/aliases".  Administrators can set
     whatever alias is appropriate in this export file on their
     central administration host.

     Those wanting to send this mail elsewhere for a specific
     machine can override that ".forward" file by adding an alias
     to the file /software/local_[hostname]/export/aliases for
     the userid "accounts".  (An installation of that package is
     required for the alias to take effect).  This alias may, but
     doesn't have to, send a copy to "admin_accounts" as well as
     to the interested individuals.

Mail (new method):

     It is not necessary to have an "accounts" passwd entry.
     Without it, the default ".forward" file will have no effect.
     Instead one may (either via the package's "export/aliases"
     file or by centralized automated alias administration) sim-
     ply do something such as setting
     "accounts->admin_accounts@adminhost" everywhere, and then
     have an alias for "admin_accounts" on the central admin
     host.

Configuring first-time user's information:

     When an account is created, the standard ".cshrc", ".pro-
     file", and ".xsession" files typically contain an invocation
     of the "first_login" program, which asks the user for finger
     data, displays some messages, and finally removes itself
     from the user's file.

     By default, the messages are produced by the "con-
     fig/share/first_time" file.

     An administration can override this file by editing, on the
     administration host, the file "config/admin/first_time",
     which will be automatically distributed to all other hosts
     in the same administration.

     Similarly, each host can have its own messages by editing
     the file "config/local/first_time", which will not be dis-
     tributed.

     Note that these files are "source"ed by a "csh" program, so
     they may source the other versions of the file if the intent
     is simply to add to, rather than replace, the standard mes-
     sages.

Account expiry:

     (Applies to the "accounts_client" package only.)

     The regional file "config/regional/grace" may contain a line
     giving the number of days of grace that an account should be
     granted between its expiry and its being disabled.

     If the decommented file is empty a default value (currently
     21) will be used.

Basic disk quota:

     (Applies to the "accounts_client" package only.)

     The regional file "config/regional/quota_basic" may contain
     a line giving the number of kilobytes of basic disk quota
     (e.g. for .cshrc files, mailboxes, etc.)  to be given to
     each account in addition to whatever other quota might be
     assigned to it via the sponsors database.  A default of 200
     kbytes will be used if this file is decomment-empty.

Configuring orphan:

     The crontab runs a program that periodically walks the
     filesystem looking for improperly owned files.  The
     behaviour of this program can be configured by the
     (non)existence of the userid "orphan" and the groups "every-
     one", and "orphan", and by the files "con-
     fig/local/orphan_ignore".  and "config/local/orphan_nfs".

     The "orphan_nfs" configuration is used by this package's
     crontab to determine which NFS-mounted filesystems will be
     examined.  See orphan(8) for other configuration details.

Configuring accounts_check:

     The crontab runs a program that periodically checks for con-
     sistency among the home directories and various user
     accounts files ("/etc/passwd", "/etc/group", etc.).  See
     "man accounts_check" for how to control the checks per-
     formed.

Configuring home directory creation:

     When the acount_update(8) program needs to create a home
     directory for a new account, it first looks for directories
     named "/u#", where "#" is a single digit.  Any such
     directories will be ignored if they contain a file called
     ".ManualHomeDirectoryCreation".

     If more than one "/u#" directory is found, the program will
     pick one randomly to start with and will cycle through them
     for each additional home directory that needs to be created.

     If no "/u#" directories are found, the directory "/u" will
     be used instead.

Configuring home directory content:

     New home directories are initialized using the templates
     defined by "config/*/init_home".  They are copied into place
     in the standard xhier configuration order (i.e.  share,
     arch, admin, regional), with the last found instance of any
     file being the one used.

     For backward compatibility, if the directory "/soft-
     ware/accounts/data/host/standard" exists, it alone will be
     used to do the initialization.  Administrators are encourage
     to remove this directory and to use the regional configura-
     tion instead.

     Note that the copying is done by following symbolic links,
     not copying them.  This means that one cannot initialize
     symbolic links in home directories.

Configuring initial .forward and .rhosts:

     Some users will automatically get accounts on many machines
     (e.g. the accounts maintenance people, or UNIX maintainers)
     and if they are not aware of them these machines might
     become sink-holes for their mail.  To avoid that problem,
     the "config/admin/common_users" file can contain lines of
     the form "userid@hostname.uwaterloo.ca".  By itself, this
     will not have any immediate effect, but whenever a new
     account is created with a matching userid, this information
     will be used to initialize the new account's ".forward" and
     ".rhosts" files, forwarding mail to and allowing rlogin
     access from the given userid and hostname.  This configura-
     tion also affects the init_home(1) program.

Configuring initial login shell:

     New accounts are created using the shell determined by "xh-
     options  -p accounts  -c initial  Shell", i.e. by the
     "Shell=" option in the files "config/*/initial".

Configuring accounts-maintenance:

     The last step of sponsor_accounts(8), which performs updates
     of account resources, will call an optional mkfinal program
     to do whatever may be needed on each local machine.  If
     "config/regional/mkfinal" is decomment-empty, it will be
     run.  Otherwise if "config/admin/mkfinal" is decomment-
     empty, it will be run.

Configuring mounted home directories:

     The file "config/regional/rquotahosts" contains lines of the
     form "hosts:filesystem" that define hosts that can, for the
     given filesystems, supply rquotad(8) service (in particular
     to the  diskquota (1) command).  Typically this will be all
     faservers, and any other NFS server that supports the rquo-
     tad(8) protocol.

     If home directories are mounted from one or more faservers,
     the file "config/regional/fashosts" should contain a list of
     the names of those hosts.  This is used by (at least) the
     mkquota(8) command so that it can initialize disk quotas on
     the servers.

     Note that the program that updates disk quotas (mkquota)
     ignores "/u" and "/u#" directories that are NFS mounted, so
     it will use the rquotad config file to determine where else
     it might be necessary to update the quota files.

Configuring group control

     Hosts with accounts managed by the sponsors mechanism nor-
     mally do not allow local control of group membership.  the
     "edit_group" configuration allows one to optionally turn all
     group membership over to local control (not recommended), or
     to allow local control for some specific groups.  See
     edit_group(8) for specific details.

Configuring id conformance:

     Some hosts may wish to conform to a common set of numeric
     uids and gids.  The "id_registry" configuration specifies
     which id registry host to use (default none), and what level
     of conformance to follow (default none).  See idregistry(8)
     for specific details.

Bugs:

     The local version of the first_time file is probably a lot
     less useful than a regional version.

Files:

     /software/accounts/config/{share,admin,local}/first_time
     /software/accounts/config/{admin,regional}/mkfinal
     /software/accounts/config/regional/grace
     /software/accounts/config/regional/homehosts
     /software/accounts/config/regional/rquotahosts
     /software/accounts/config/regional/fashosts
     /software/accounts/config/local/orphan_ignore
     /software/accounts/config/local/orphan_nfs
     /software/accounts/data/standard/first_login
     /software/accounts/config/regional/edit_group
     /software/accounts/config/*/init_home
     /software/accounts/config/*/initial
     /u#/.ManualHomeDirectoryCreation

Copyright:

     Copyright (C) 1992, 2005, MFCF, University of Waterloo

accounts_backup command (WAS VERY USEFUL)

Name:

     accounts_backup - save copies of some important files.

Synopsis:

     accounts_backup

Description:

     accounts_backup makes copies of some important files, such
     as /etc/passwd, /etc/group, .../host/users, and secu-
     rity/data/super_users.

Copyright:

     Copyright (C) 1988, MFCF, University of Waterloo.

accounts_check command

Name:

     accounts_check - check inconsistencies in accounts files

Synopsis:

     accounts_check [-doRegionalClient] [-checkCoursePasswords]
     [+checkUsersFile] [+checkRootPasswords] [+checkAllHomes]

     Note that default options may vary from machine to machine
     (see the configuration section below for details).  Use
     "accounts_check {+|-}HELP" to find the current defaults.

Description:

     accounts_check examines the files "/etc/passwd",
     "/etc/group", "/software/accounts/data/host/users", and
     "/software/security/data/super_users", "/software/secu-
     rity/data/securid_users", and reports any inconsistencies
     between them.

     Unless the "+doRegionalClient" option is given, on regional
     clients the program will skip certain tests that would
     already have been performed on the regional server.

     Warnings include:

     -    duplicate entries.

     -    entries out of order.

     -    passwd entries with non-existent home directories.  If
          an account is really not supposed to have a home direc-
          tory, the value "/dev/null" should be entered into the
          passwd file.
          Unless the "+checkAllHomes" option is specified, miss-
          ing home directories that begin with "/software/", and
          accounts that come with missing home directories in the
          stock passwd file will not be reported since such prob-
          lems are the responsibility of the corresponding xhier
          package or software vendor and are not something that
          can be fixed by the people normally responsible for the
          passwd file.
          Home directories will not be checked at all on xhier
          regional clients unless at least one of the "+checkAll-
          Homes" or "+doRegionalClient" options are given.

     -    missing required groups or userids.

     -    misnumbered aliases.  If the groups "other" and "users"
          both exist, they should have the same gid.  Similarly
          for "root" and "wheel".

     -    course accounts with passwords other than "*".  Course
          accounts are considered to be any userid ending with
          three digits and possibly a single letter.  This check
          can be disabled by using the "-checkCoursePasswords"
          option.  This can often be done in the "admin" configu-
          ration file to avoid having to individually configure
          every machine individually.

     -    discrepancies between the passwd file and users file.
          Since some administrations do not record data for all
          accounts in the users file, this option is by default
          disabled, but can be enabled, typically in the admin
          configuration file, by using the "+checkUsersFile"
          option.

     -    userids in the group file that are missing from the
          passwd file.

     -    gids in the passwd file that are missing from the group
          file.

     -    userids in the super_users file that are missing from
          the passwd file.

      -   root accounts (uid=0) with valid login passwords and
          shells.  Since some architectures require a root pass-
          word to work, this check is by default disabled, but
          can be enabled by using the "+checkRootPasswords"
          option.

     -    userids in the passwd file but not the users file (and
          vice versa).  This test is currently not performed.

Configuration:

     The files "/software/accounts/config/<type>/accounts_check",
     where "type" is one of "admin", "regional", or "local", may
     be used to control some of the checks performed by this pro-
     gram by entering the default values for any of the command
     line options one per line into whichever of these configura-
     tion files are appropriate.

     There is an additional option,
     "RootPasswordHosts=host1,host2,...", that can be used only
     in an admin config file to allow some set of machines to
     bypass the check for valid root passwords.  Setting this
     automatically implies "+checkRootPasswords" if the current
     host is not in the list, and "-checkRootPasswords" if it is
     in the list, in both cases regardless of any explicit set-
     tings of that option in any of the configuration files.

     Options given on the command line always override defaults
     set by configuration files.

See Also:

     syntax(i)

Copyright:

     Copyright (C) 1988, 1996 MFCF, University of Waterloo.

accounts_check_region command

Name:

     accounts_check_region - record and check xhier regions

OBSOLETE:

     These hostin groups have now moved to the xhier package
     where they should have been in the first place.  See
     RT#12751.

Synopsis:

     accounts_check_region {Client|Server}

Description:

     accounts_check_region is run by the Install script of the
     accounts package, its argument indicating whether xh-is-
     regional-server(8) thinks the host is an xhier regional
     server or client.

     On an xhier regional server machine, checks are made to
     ensure that this is the only machine claiming to be the
     server for this region, that this server machine does not
     also claim to be a regional client, and that all clients
     have recently (within 25 days) registered themselves as
     regional clients.

     On an xhier regional client machine, checks are made to
     ensure that this client machine does not also claim to be a
     regional server, that there is exactly one host claiming to
     be a regional server, and that this server has recently reg-
     istered itself as the regional server.

Files Used:

     The change date on each file indicates when this program
     last registered the host as the regional server or as a
     client.
     /software/accounts/data/regional-server/<hostname>
     /software/accounts/data/regional-clients/<hostname>*

     Note that if the configuration of a region changes, one may
     remove any of the above files, but one should never manually
     create or rename any of them.  That is this program's job.

Bugs:

     The command should be called xh-check-region(8), and all of
     this should be in the xhier package.  I don't understand why
     it isn't.

     Actually, since it makes changes rather than simply report-
     ing problems, it shouldn't even have the word "check" in its
     name.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

check_rhosts command

Name:

     check_rhosts - report dubious .rhosts entries

Synopsis:

     check_rhosts [userid=]userid * [+Verbose]

Description:

     This command is still somewhat under development.

     Rule #1:  Hostname must be in our domain.

     Rule #2:  Userid must be the same user.

     Rule #3:  There is no rule #3.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

currentdisk command

Name:

     currentdisk - display usage for local file systems with
     quota

Synopsis:

     currentdisk [+FileSystems] [+Headings] [+Percent]

Description:

     This program displays the current disk usage, as reported by
     the kernel, for all local file systems with disk quota.

     Fields are separated by a colon, and by default only the
     userid and number of kilobytes used are displayed.

     +Percent displays the quota and percentage in use; +FileSys-
     tems displays the name of the filesystem; and +Headings pre-
     cedes the output with the following line (omitting fields as
     necessary):
     Userid:Filesystem:kbytes:Quota:Percent

Examples:

     # Find top-ten users
     currentdisk |  sort  -t :  -k 2,2nr  | head -10  | align -f:

     # Find over-quota users
     currentdisk +percent | sort  -t :  -k 4,4nr  -k 3,3nr | head | align -f:

Configuration:

     There are two regional configuration files:

     /software/accounts/config/regional/accounting_ignore
          all filesystems named in this file are silently
          ignored.

     /software/accounts/config/regional/accounting_nfs
          any filesystems named in this file are processed even
          though nfs mounted.

     Both files are decommentable and have lines with the format
     "hostname:filesystem", where the colon may be surrounded by
     white-space.

     Note that the hostname is the name of the host in the region
     (typically the regional server) that is supposed to process
     the disk accounting for this filesystem (typically nfs
     mounted from a machine not part of the region (e.g. a
     faserver)); it is not the name of the host where the files
     are mounted from.

Copyright:

     Copyright (C) 1999,2000,2007 MFCF, University of Waterloo.

disable_user command

Will something like this be easily available to, e.g. MFCF consultants and CSCF help desk?

Name:

     disable_user, enable_user - disable or enable an exceptional
     user

Synopsis:

     disable_user [userid=]userid [Reason='The reason.']
                  [SecretReason='The real reason.']
                  [cannedMessage=various-message-names]
     enable_user [userid=]userid [Reason='The reason.']

Description:

     This command should not be used except under unusual circum-
     stances.  It is not intended for normal accounts mainte-
     nance, but for cases where an account must be disabled imme-
     diately by a non-accounts person in order to prevent further
     abuse by the user.

     disable_user allows someone in group operator or accounts to
     disable the specified userid's account by changing the login
     shell.

     Exactly one of Reason= or cannedMessage= must be given.  The
     new shell will display this reason whenever the user
     attempts to sign on.  The names of the available canned mes-
     sages may vary from machine to machine, but can be found at
     any time using the command "disable_user -HELP".  Use "+"
     instead of "-" for even more details.

     An optional SecretReason= can be recorded, but not shown to
     the user.  This could be used to convey information to the
     people that might be reenabling the account without making
     that information available to the user.

Notes:

     The "disable_user" command will complain if you try to use
     it without the "accounts_client" package, which is not a
     dependency of the "accounts" package, and must be explicitly
     requested before this command can be used.  This dependency
     was intentionally not made so as to avoid dragging in too
     many xhier packages for those that don't want it.

Files Used:

     /software/accounts/logs/disable
     /software/accounts/config/*/disabled_messages/*
     /software/accounts/data/disabled/secret_why/userid
     /software/accounts/data/disabled/why/userid

Copyright:

     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

disabled_shell command

Part of the account disabling feature.

Name:

     disabled_shell - politely reject a user

Synopsis:

     /xhbin/disabled_shell

Description:

     The disabled_shell looks for specific messages for the user,
     displays them (or a generic rejection message if none is
     found), sleeps for a few seconds, and finally exits.

Files Used:

     "/software/accounts/data/disabled/why/<userid>"

See Also:

     disable_user(8).

Copyright:

     Copyright (C) 1995, 2000, MFCF, University of Waterloo.

edit_finger command (Obsolete)

Privacy overrides publication in the current world order.

Name:

     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.

Synopsis:

     edit_rhosts userid
     edit_forward userid
     edit_shell userid
     edit_finger userid

Description:

     edit_rhosts etc. allow someone in group accounts to edit the
     ".rhosts" or ".forward" file, or shell or finger information
     of any userid with uid not less than 32 that has an
     encrypted password beginning with the "*" character.

     This is primarily intended for setting up course accounts
     and other multiple-user userids.  Such userids should not
     have passwords since that would allow anonymous access.

See Also:

     setpasswd(8) - edit or change some fields in passwd file.

Copyright:

     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

edit_forward command (Unimportant)

Name:

     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.

Synopsis:

     edit_rhosts userid
     edit_forward userid
     edit_shell userid
     edit_finger userid

Description:

     edit_rhosts etc. allow someone in group accounts to edit the
     ".rhosts" or ".forward" file, or shell or finger information
     of any userid with uid not less than 32 that has an
     encrypted password beginning with the "*" character.

     This is primarily intended for setting up course accounts
     and other multiple-user userids.  Such userids should not
     have passwords since that would allow anonymous access.

See Also:

     setpasswd(8) - edit or change some fields in passwd file.

Copyright:

     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

edit_group command

Provided limited privilege for, e.g. course co-ordinators At some point it was decided there was no need to use Posix groups for anything.

Name:

     edit_group - set or change /etc/group entries

Synopsis:

     edit_group [group=]groupname [+Create] [+Differences]
     [Add=userid[,...]]*  [Delete=userid[,...]]*  [Comment='To
     remember why.']

Description:

     edit_group allows one to create or change the "/etc/group"
     entry for the given group.  One may not add any userids to
     the group "none", since that group by definition is the
     group to which no users belong.

     [group=]groupname
          is the name of the group to be edited.

     +Create
          must be given if a new group is to be created, and must
          not be given otherwise.

     Add=userid,...
          specifies userid(s) to be added to the group.

     Delete=userid,...
          specifies userid(s) to be deleted from the group.

     Comment=Why.
          gives an optional comment to be entered into the log
          file.

     +Differences
          shows the differences between the old and new entries
          and confirms that they should be applied.

Configuration:

     The file "/software/accounts/config/regional/edit_group" may
     contain the following options:

     MaxGroups=number
          restricts the maxumum number of groups that any userid
          may belong to.  This should be used on systems where
          NFS software causes problems when someone is in more
          than 15 groups.  The default is 0, which means unlim-
          ited.  Note that it is more efficient to omit this
          option (or to set it to 0), than to set it to a very
          large number.

     LocalControl=TRUE
          allows this command to be used even though the "/soft-
          ware/accounts/data/users" file indicates that some
          accounts are remotely controlled by sponsors data.
          It's recommended that you don't use this option.

     SubGroups=group1_## group2_## ...
          allows local control of the specified subgroups, inde-
          pendent of the sponsored control of all other groups.
          The entry in the configuration file contains literal
          number signs ("#"), and not real digits.  In use, typi-
          cally the groups will be like "cs446_03" or "cs452_17",
          with the number of number signs indicating the number
          of digits allowed in the subgroup.  If an account
          exists with a name that matches the group name (e.g.
          "cs446"), that account will be allowed to make addi-
          tions and deletions to the account's subgroups.

Bugs:

     Doesn't yet allow the renaming of groups.

     Doesn't yet allow the deletion of groups.

Files Used:

     /software/accounts/logs/edit_group
     /software/accounts/config/regional/edit_group
     /etc/group
     /etc/group.lock

See Also:

     setpasswd(8) - edit or change some fields in passwd file.

Copyright:

     Copyright (C) 1995,2003, MFCF, University of Waterloo.

edit_rhosts command (Unimportant)

Name:

     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.

Synopsis:

     edit_rhosts userid
     edit_forward userid
     edit_shell userid
     edit_finger userid

Description:

     edit_rhosts etc. allow someone in group accounts to edit the
     ".rhosts" or ".forward" file, or shell or finger information
     of any userid with uid not less than 32 that has an
     encrypted password beginning with the "*" character.

     This is primarily intended for setting up course accounts
     and other multiple-user userids.  Such userids should not
     have passwords since that would allow anonymous access.

See Also:

     setpasswd(8) - edit or change some fields in passwd file.

Copyright:

     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

edit_shell command (Consider)

Name:

     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.

Synopsis:

     edit_rhosts userid
     edit_forward userid
     edit_shell userid
     edit_finger userid

Description:

     edit_rhosts etc. allow someone in group accounts to edit the
     ".rhosts" or ".forward" file, or shell or finger information
     of any userid with uid not less than 32 that has an
     encrypted password beginning with the "*" character.

     This is primarily intended for setting up course accounts
     and other multiple-user userids.  Such userids should not
     have passwords since that would allow anonymous access.

See Also:

     setpasswd(8) - edit or change some fields in passwd file.

Copyright:

     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

enable_user command

Name:

     disable_user, enable_user - disable or enable an exceptional
     user

Synopsis:

     disable_user [userid=]userid [Reason='The reason.']
                  [SecretReason='The real reason.']
                  [cannedMessage=various-message-names]
     enable_user [userid=]userid [Reason='The reason.']

Description:

     This command should not be used except under unusual circum-
     stances.  It is not intended for normal accounts mainte-
     nance, but for cases where an account must be disabled imme-
     diately by a non-accounts person in order to prevent further
     abuse by the user.

     disable_user allows someone in group operator or accounts to
     disable the specified userid's account by changing the login
     shell.

     Exactly one of Reason= or cannedMessage= must be given.  The
     new shell will display this reason whenever the user
     attempts to sign on.  The names of the available canned mes-
     sages may vary from machine to machine, but can be found at
     any time using the command "disable_user -HELP".  Use "+"
     instead of "-" for even more details.

     An optional SecretReason= can be recorded, but not shown to
     the user.  This could be used to convey information to the
     people that might be reenabling the account without making
     that information available to the user.

Notes:

     The "disable_user" command will complain if you try to use
     it without the "accounts_client" package, which is not a
     dependency of the "accounts" package, and must be explicitly
     requested before this command can be used.  This dependency
     was intentionally not made so as to avoid dragging in too
     many xhier packages for those that don't want it.

Files Used:

     /software/accounts/logs/disable
     /software/accounts/config/*/disabled_messages/*
     /software/accounts/data/disabled/secret_why/userid
     /software/accounts/data/disabled/why/userid

Copyright:

     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

findall command

NAME

     findall - find files owned by any of a group of users

SYNOPSIS

     server findall [ f=fileout ] [ d=dirout ] [ u=userin ]
     directory users ...

DESCRIPTION

     Findall locates files under the specified directory owned by
     any of the indicated users.  It's similar to find(1) but is
     faster at doing this simplified task.

     Findall prints the names of all the located files on the
     standard output.  Options f=fileout and d=dirout can be used
     to direct the output of file names and directory names
     respectively to ``fileout'' and ``dirout''.  Option u=userin
     can be used to specify a file of usernames, one per line,
     instead of specifying usernames on the command line.

     Findall traverses directories in depth-first order, so for
     instance file names that it prints can safely be removed in
     the order given.

     Findall is typically used by administrative shell scripts
     that want to locate files owned by users who are about to be
     deleted.

EXAMPLES

     findall /u user1 user2 user3
          find files in /u owned by user1, user2 or user3

     findall f=/dev/null /u user1 user2 user3
          Find files under /u but only print the names
          of the directories.

SEE ALSO

     find(1)

fsuserclean command

Name:

     fsuserclean - find and process files owned by deleted users

Synopsis:

     servers/fsuserclean [Orphan='orphan'] [Remove=/u[,...]]
     [Start=/] Uids=filename

Description:

     fsuserclean walks the filesystem tree rooted at "Start", and
     finds all the files that belong to any of the numeric uids
     given (one per line) in the "Uids" file, removing any that
     are within any of the "Remove" subtrees.  For any files that
     aren't in those subtrees, it reports them on standard output
     and chowns them to the "Orphan" userid.

     NFS filesystems are ignored unless "Start" itself is NFS
     mounted.  Except for those paths given on the command-line,
     no symbolic links are followed.

Options:

     [Orphan=orphan]
          Userid to which to chown non-deleted files.  Give an
          empty string to suppress this action.  If the default
          is used and that userid does not exist, this option
          will be silently ignored.

     [Remove=/u[,...]]
          Comma-separated list of filesystems from which to
          remove rather than chown user files.

     [Start=/]
          Filesystem root.

     Uids=
          File containing numeric uids, one per line, whose files
          are to be removed.

See Also:

     rmallusr(8)

Copyright:

     Copyright (C) 2002, MFCF, University of Waterloo.

id_renumber command

Name:

     id_renumber - walk directory tree changing file ownership

Synopsis:

     id_renumber [+Quiet] [+Test] [+NFS] [Map=map]...  [+Stdin]
     [directory]...

Where:

     +Quiet
          produces no output if nothing is renumbered

     +Test
          shows changes which would be made without making them

     +NFS allows NFS filesystems to be traversed.

     Map=map
          specifies an id mapping to perform.

     +Stdin
          causes id mappings to be read from standard input.

     directory
          must be an absolute pathname (begin with "/" )

Description:

     Id_renumber walks directory trees performing uid or gid map-
     ping on files and directories.

     The Test option can be specified to cause the output to
     indicate what files would have ownership changed, without
     actually performing the changes.

     Normally, the output begins and ends with headers indicating
     start time and finish time, even if no other output is gen-
     erated.  If the Quiet option is given, those headers will
     only be generated if other output occurs.

     id_renumber does not follow symlinks or NFS mounted file
     systems.  NFS mounted filesystems can be checked by using
     the +NFS option, but in that case non-NFS filesystems will
     be ignored.

     While walking a tree, it will skip (stop walking) any paths
     in the decomment(1)able file "/software/accounts/con-
     fig/local/orphan_ignore".  These paths must begin with "/"
     If one of these roadblock paths is a symlink, it will be
     treated as its target.  (See "Note" below).

Mappings:

     Mappings must be of the form:

          uid:oldnumber:newnumber
     or
          gid:oldnumber:newnumber

     There may be leading or trailing blanks, but no embedded
     blanks.  Comments beginning with "#" may be placed on the
     same line, after the mapping.  The input on stdin may also
     contain blank lines (containing zero or more space charac-
     ters), or comment lines beginning with "#" after zero or
     more space characters, which will be ignored.

Diagnostics:

     The program must be given at least one mapping to perform.
     If no mappings are found, the program complains and exits
     prematurely, on the assumption that there is no point in
     taking the possibly very long time to walk all the directory
     trees to do essentially nothing.

Note:

     Because the roadblocks are implemented using device and
     inode numbers, if the "orphan_ignore" file contains
     "/one/two" and id_renumber is invoked with path
     "/one/two/three", this tree will not be ignored since the
     roadblock will never be encountered.

     Similarly, any "orphan_ignore" path that contains a symlink
     will use the device and inode numbers of the target.  E.g.
     if "/one/two -> /eight/nine/ten" then roadblocks "/one/two"
     and "/eight/nine/ten" will have the same effect, as will
     "/one/two/three" and "/eight/nine/ten/three".

Caveats:

     id_renumber performs no sanity checking on its input.  If
     differing mappings are given with the same  oldnumber, the
     later one is the only effective one.  Remappings will not be
     performed.  Multiple  oldnumbers can be mapped to the same
     newnumber; after all that might be appropriate in some
     cases.

     Also, if a newnumber also occurs as an oldnumber, the change
     will end up being made.  That is, you could actually switch
     two ids by mapping each to the other, since the result of
     the mapping will not be evaluated.  (A problem might occur
     if the mapped inodes are moved to a different place in the
     directory trees, and later walked again).

     The given directories are walked from right to left,  I.e.
     the directory specified last on the line is processed first.

Examples:

          # map gid 60042 to gid 1 in given directories
          id_renumber map=gid:60042:1 `pwd`/test `pwd`/test2

          # show effect of mapping uid 109 to 60042, but don't make changes
          id_renumber +test map=uid:109:60042 `pwd`/test

          # also apply mappings read from stdin
          id_renumber +s m=uid:109:60042 `pwd`/test < file

Bugs:

     It seems strange to use "/software/accounts/con-
     fig/local/orphan_ignore" to roadblock this program, but it's
     probably appropriate.

     It could be argued that id_renumber should not require the
     user to change relative paths to absolute paths, but should
     determine the absolute paths itself.

     You could actually switch two ids by mapping each to the
     other, since the result of the mapping will not be evalu-
     ated.  But a problem might occur if the mapped inodes are
     moved to a different place in the directory trees, and later
     walked again.  Therefore, since this is not theoretically
     sound, perhaps it should be disallowed.

See Also:

     accounts-config(7) - configuring the accounts package
     orphan(8) - look for unowned files
     decomment(1) - remove shell-style comments

Copyright:

     Copyright (C) 2008, MFCF, CSCF, University of Waterloo.

idregistry command

Name:

     idregistry - send request to the uidregd id registry daemon

Synopsis:

     idregistry {Request|Require|Report|Control} [RegistryHost=]
     [Conformance=None|Advisory|Strict] [Type=User|Group] [name=]

Where:

     RegistryHost=
          specifies the name of the host that registers our user
          and group ids.

     Conformance={None|Advisory|Strict}
          specifies our conformance level. (See "Configuration"
          section below).  One would normally not specify this,
          letting idregistry use the default from the "accounts"
          package configuration.

     Type specifies whether the names and id numbers are for
          userids or groups.

     name specifies a userid or group name.  If the name is sim-
          ply "-", standard input should contain a one-per-line
          list of names.  For reporting id maps, names must
          acually be pairs of the form "userid:uid" or
          "group:gid".  The "name=" keyword may be omitted,
          except when using a name of "-" to indicate standard
          input.

Description:

     idregistry provides a command-line interface to the
     uidregd(8) id registry daemon in the uid-registry package.

     Except for requests for current information ("idregistry
     request"), this command does not generally need to be used
     manually.  Automated account maintenance programs automati-
     cally query the registry whenever creating new userids or
     groups, and ensure that existing IDs get regularly reported,
     to prevent them from expiring.

     Request and Require
          supply one or more names and ask the daemon for corre-
          sponding "name:id" pairs.  If the name does not cur-
          rently exist in the database, the id will be "UNKNOWN"
          for Requests, and will cause a new uid to be assigned
          and registered for Requires.  Except when a new id
          pairing was generated this will not update the "last-
          seen" date in the registry.

     Report
          supplies one or more "name:id" pairs for the daemon to
          register as currently used.  If a pair matches what is
          in the registry no output is generated, and the reg-
          istry "last-seen" information will be updated.  Other-
          wise, if there is a mismatch, the pairing is echoed
          back, possibly with a full uwuserid even if the submit-
          ted name was truncated to 8 characters, and possibly
          with the id number part changed to "NAMEINUSE" or "IDI-
          NUSE".

     Control
          makes a privileged request of a special action of the
          daemon.  Currently available actions (specified by set-
          ting the name parameter) are Die and Cleanup.  The for-
          mer simply kills the daemon, while the latter requests
          that the filesystem version of the database be cleaned
          up (e.g. remove entries which have been unreported for
          a long time).

Output:

     For most subcommands, output is of the form "name:number".
     The remote daemon may supply a brief error code in place of
     the number:

     IDINUSE
          The reported "number" is already assigned to a differ-
          ent name.

     NAMEINUSE
          The reported "name" is already assigned to a different
          id number.

     UNKNOWN
          The given "name" is not in the registry.

     More serious problems may also be returned:

     *UNAVAILABLE
          No more id numbers are available for assignment.  (i.e.
          ask someone to reduce the daemon's configured data
          expiry time).

     *NOID
          The reported number field was empty or non-numeric.

     *NOCOLON
          The reported "name:number" didn't contain a colon.

Configuration:

     The files "/software/accounts/config/*/id_registry", where
     "*" is any of "share", "admin", and "regional", may contain
     the following options:

     RegistryHost=hostname
          The name of the host running the idregd(8) daemon.  The
          shared default is to have no such daemon.  For idreg-
          istry to work, this value must be set.

     Conformance={strict|advisory|none}
          How this region wishes to conform to the registry
          host's standard ids.  "none" means that nothing hap-
          pens.  "strict" means that all new passwd and group
          entries created by the sponsor mechanism or by
          edit_group(8) will automatically conform to the reg-
          istry host's standard ids.  If conformance isn't possi-
          ble, the account or group will not be created.  In
          addition, a nightly cron job will register the host's
          passwd and group files with the registry and report any
          discrepancies by mail to "accounts".  "advisory" means
          that new ids will conform to the standard whenever pos-
          sible, and ids will be reported to the registry each
          night, but any discrepancies will be ignored.  The
          shared default is "none".

See Also:

     uidregd(8) - maintains uid and gid registry database

Copyright:

     Copyright (C) 2003, MFCF, University of Waterloo.

initialize_users command

Name:

     initialize_users - update the vendor and xhier entries in
     the data/users file

Synopsis:

     sort  -t :  -k 1,1  users  |  initialize_users  >users.new

Description:

     For each entry in the vendor passwd file that has an exist-
     ing entry in the "/etc/passwd" file, initialize_users makes
     sure that there is a corresponding entry in the data/users
     file, copying the finger information to the payment[sic]
     field, and setting the type field to "vendor".

     For each existing non-vendor account in any "/.soft-
     ware/*/*/export/passwd" or "/soft-
     ware/xhier/data/region/passwds/*" file, the type field is
     set to "xhier" and the info field is set to a comma-sepa-
     rated list of packages that require the account.

See Also:

     users(5).

Files Used:

     /software/setpw/config/arch/vendor.passwd

Copyright:

     Copyright (C) 1997,2009 MFCF, University of Waterloo.

make_cifs_exports command

Name:

     make_cifs_exports - rebuild the links to user cifs_exports
     directories

Synopsis:

     servers/make_cifs_exports

Description:

     The make_cifs_exports command creates symlinks under "/soft-
     ware/accounts/data/cifs_exports/all" from all
     "/u[0-9]/*/cifs_exports," or if they don't exist, from all
     "/u/*/cifs_exports".

     In addition, any /u-type subdirectories found in "/soft-
     ware/accounts/config/local/other_cifs_homes/" will also be
     searched, but no symlinks created in the first pass will be
     replaced.

     The directory is intended to be mounted on a PC client to
     allow easier browsing of other user's files.

     The command is normally run from the package's crontab on
     the regional server.

Options:

     None.

Files Used:

     "/software/accounts/data/cifs_exports/all/"
     /u/*/cifs_exports
     /u[0-9]/*/cifs_exports
     /software/accounts/config/local/other_cifs_homes/*/*/cifs_exports

Copyright:

     Copyright (C) 1998, 2003, MFCF, University of Waterloo.

mergefasquotas command

Name:

     mergefasquotas - Generate a quotas file based on fragments
     generated by mkquota.

Synopsis:

     mergefasquotas hostname [fasgroupname]*

Description:

     This command generates a quotas file on the faserver "host-
     name" from quotas file fragments generated by the "mkquota"
     command and defined by "fasgroupname" and then reinitilizes
     quotas on the faserver.

Note:

     This command assumes the faserver has only one volume.

See Also:

     mkquota(8) - set all quotas according to the .../users file.

Author:

     Written in July 2003 by Jason Testart, CSCF, University of
     Waterloo.

mkfasquotafile command

Name:

     mkfasquotafile - generate a fas quota file from  a users
     file.

Synopsis:

     mkfasquotafile [FileSystem=] [DefaultQuota=] [UserFilename=]
     [fasVolume=] [FasHost=]

Where:

     FileSystem=
          specifies the name of the filesystem, as known to the
          relevant FAServer, on which to grant quota.

     DefaultQuota=
          specifies a default amount to use for users for whom no
          sponsored amount can be determined.  Units should be
          specied as "K" (default), or "M", or "G".

     UserFilename
          specify a filename to use instead of the default /soft-
          ware/accounts/data/users.

     fasVolume=
          specify a name for the FAServer volume, in place of the
          default /vol/.

     FasHost=
          specifies the name of the FAServer host to use.  (This
          is reserved for future use; i.e. currently not used for
          anything).

Description:

     This command writes on stdout a FAServer-style quota file
     (fragment), which would allocate quota for users as speci-
     fied in the indicated UserFilename (default /soft-
     ware/accounts/data/users), according to the specified param-
     eters.

Notes

     Normally an automated process will be used to update the
     /software/accounts/data/users file, or equivalent.

     Normally, another automated process will take output from
     one or more relevant invokations of mkfasquotafile and com-
     bine them, perhaps with other fragments, to make a complete
     quota file for a FAServer.

Files Used:

     /etc/passwd or equivalent
     /software/accounts/data/users

Copyright:

     Copyright (C) 2008, CSCF, MFCF, University of Waterloo.

mkhomes command (Somewhat Important)

This is probably less important than rmallusr. Standard Ubuntu Linux provides means to create home directories, e.g. on first login. Creating is easy. Removing the directories later, at an appropriate time, to recover disk space, is harder.

Name:

     mkhomes - create and initialize home directories

Synopsis:

     mkhomes

Description:

     mkhomes is normally invoked via the sponsor_accounts(8) pro-
     gram.  Any non-existent home directories of the form
     "/u/realuserid" or "/u#/realuserid" in the "/etc/passwd"file
     are created (mode 0751) and initialized.

See Also:

     realuser(1), init_home(1), link_homes(8).

Copyright:

     Copyright (C) 1996 MFCF, University of Waterloo.

mkmerge command

NAME

     mkusers, mkmerge - merge commandline or file data to update
     and create user accounts

EXAMPLE

     mkusers userid

     You probably don't really want to use any of the other
     options.

     Though maintained by us, this program is no longer used by
     MFCF or CSCF.

SYNOPSIS

     mkmerge [ -a ] [ -e ] [ -f ] [ -m ] [ -u[u] ]
           [ -l uidlen ] [ -k num_fs ] [ -P passwd ] [ -U users ]
           pwd_merge usr_merge

     mkusers [ -a ] [ -e ] [ -f ] [ -m ] [ -u[u] ]
           [ -l uidlen ] [ -k num_fs ] [ -P passwd ] [ -U users ]
           [ -p 'student'|'batch'|password ] [ -c comment ]
           [ -g group ] [ -h home ] [ -s shell ] [ -t type ]
           [ -q quota ] [ -i imagen ] [ -r resource ]
           [ -n 'fullname' ] [ -v vmid ] [ -b vmbillcd ]
           userid:sponsor ...

     where
     -m   - do *not* run mkpw after update,
            normally one rebuilds the passwd dbm to install changes
     -a   - add-only, do *not* update existing users,
            ie create an account, but do nothing if it already exists
     -e   - existing accounts only, do *not* create new users,
            ie update info fields for existing accounts only
     -f   - force finger info to be overidden by the update,
            normally values for active users are retained
     -u   - verify mode, do *not* update active files or logfile
            -uu, update active files, do *not* create home_dirs etc.
     -P   - flag: next option is to be used as active passwd filename
            also turns off creation of home_dirs, quota updates etc.
            default: /etc/passwd, /etc/ypsrc/mad/passwd (SUN domains)
     -U   - flag: next option is to be used as active users filename
            also turns off creation of home_dirs, quota updates etc.
            default: /etc/users,  /etc/ypsrc/mad/users  (SUN domains)
     -p   - flag: next option is the password or one of the keywords
            ('student','batch')
            default: '*No*Password*' unusable password
     -c   - flag: next option is a comment inserted into us_type
            (see mkstuds for valid student classes xystudent-zzzz)

     the remaining options can be set in /software/accounts/data/standard/stdopts
     -l   - maximum userid length
            default: UIDLEN (pre-programmed constant, eg 12)

     -g   - flag: next option is a valid group name in /etc/group
            default: 'other'
     -h   - flag: next option is the home directory or filesystem/,
            default: /u[0-9]*/userid  (selected by max freespace)
     -k   - count of home filesystems over which to spread users,
            default: 0 (don't spread, use maximum free space instead)
     -s   - flag: next option is the users shell
            default: /bin/csh
     -t   - flag: next option is the type of user, used to select
            initial .dotfiles from /software/accounts/data/standard/{type}
            default: 'other'
     -q   - flag: next option is the disk soft quota,
            the hard quota is computed as 120% of the soft quota
            use a quota of 0 to indicate that no quota is desired
            default: 1000 disk blocks
     -i   - flag: next option is the imagen pagelimit
            default: 0    no imagen access
     -r   - flag: next option is the dollar resources (not used)
            default: -1   unlimited
     -n   - flag: next option is usually 'fullname',
            a comment field for finger information
            default: ""  (mandatory on some systems - eg Eng)

     the next options are activated by placing an entry in stdopts
     -v   - flag: next option is a VM id number (dcsu)
            default: (mandatory entry)
     -b   - flag: next option is a VM billcode  (dcsu)
            default: (mandatory entry)
     -d   - flag: next option is a Sun domain (not used)
            default: 'mad' (maintenance and development)

     userid:comment - the userid string, and an optional comment
            inserted into the us_payment field. If a keyword has
            been given for a password, then the actual password
            is taken from this comment field. Usually this field
            gives the sponsor or reason for the account.
            (For MFCF students, this is the student number).

DESCRIPTION

     Mkusers creates accounts or updates accounts info for one or
     more users as specified by the selected options and/or cor-
     responding system defaults.

     The entries are built in memory and merged with the active
     system files as documented in mkmerge below.

     Mkmerge merges information contained in the passwd- and
     users-formatted files pwd_merge and usr_merge with that in
     the active or indicated files, and carries out all appropri-
     ate system tasks to update or create new users as required.
     Updates to the merge entries are written back out to the
     merge files so they reflect the actual active account after
     merging (For example, the actual value of the uid number
     used in creating the account will be returned).

     The vmid and vmbillcd options are local options used only on
     WatDcsu.

NOTE

     Consult your local accounts person for administration prac-
     tices in specifying information and commentary fields.

     The presence of a null string ("") in the standard options
     file /software/accounts/data/standard/stdopts makes the cor-
     responding option mandatory.

     The format of the stdopts file is:
         [     keyword = value  [     keyword = value  [     ...
     where current keywords are {umask, group, home, shell, type,
     name, quota, impages, dollars, vmid, vmbillcd, domain}.

CONFIGURATION OPTIONS

     The directories "/software/accounts/config/*/init_home" con-
     tain templates for new home directories.  They are copied
     into place in the standard xhier configuration order (i.e.
     share, arch, admin, regional), with the last found instance
     of any file being the one used.

     For backward compatibility, if the directory "/soft-
     ware/accounts/data/host/standard" exists, it alone will be
     used to do the initialization.  Administrators are encourage
     to remove this directory and to use the regional configura-
     tion instead.

     Note that the copying is done by following symbolic links,
     not copying them.  This means that one cannot initialize
     symbolic links in home directories.

FILES

     /etc/passwd                        the password file itself
     /etc/ptmp                          the password lockfile
     /software/accounts/data/users      local additions to passwd
     /u/username                        user home directory
     /u[0-9]+/username                        ditto
     /software/accounts/data/standard   default options
     /software/accounts/config/*/init_home default home directory
                                        templates and options
     /software/accounts/data/host/standard local overrides
                                        of default (deprecated)
     /u[0-9]/quotas                     system quota entries
     /software/accounts/logs/change     log file

SEE ALSO

     accounts_admin(i), rmusr(8), undelete(8), edquota(8),
     vipw(8), add_all(8), .login(5), .profile(5)

mkpw command

NAME

     mkpw - update the passwd dbm files

SYNOPSIS

     mkpw

DESCRIPTION

     Mkpw is a kludge used to update the passwd dbm files from
     its source.

FILES

     /etc/passwd    the password file itself
     /etc/passwd.pag
     /etc/passwd.dir
     /etc/ptmp password file lock

mkquota command

Name:

     mkquota - set all quotas according to the .../users file.

Synopsis:

     mkquota [+TEST] [-Verbose] [fasgroup=...]  [userid]*

Description:

     This command finds all users with home directories on file
     systems with quota and sets their quota according to the
     value in the .../users file.

     A list of file systems with quotas and a summary of all
     accounts updated are displayed (updates will not be shown
     for faserver filesystems).  Userids without entries in the
     .../users file are also reported.

     If the command is given the argument "+test", the output is
     the same, but no actual updates are performed.

     Unless the option "-verbose" is given, on systems with
     faserver quotas, the program will not exit until the quotas
     are properly initialized, displaying the current state of
     the initialization every few seconds until they are.

     The value of the option "fasgroup" is only used when there
     are faserver quotas in use.  When used, the option will
     maintain a "quotas.fasgroupname" on the faserver instead of
     the standard quotas file.

     If any userids are given on the command line, if possible
     only those user's quotas will be set.

     Normally the configured quota is assigned to each user's
     home directory's filesystem, and a minimal quota is assigned
     to every other filesystem.  However (for various historical
     reasons), every user with an explict entry in "/etc/group"
     will be assigned the quota on all filesystems that have
     quota controls.  One may take advantage of this by creating
     a dummy group to cause the users in that group to have the
     same disk quota on all filesystems.  Or, to affect all users
     on the machine, one may create a memberless /etc/group entry
     called "quota_everywhere".

Configuration:

     If the ".../fashosts" file contains any host names, a
     faserver quota file will be constructed, copied to those
     hosts, and the quotas on those faservers will be reinitial-
     ized unless the "fasgroup" option is used.

     If the "fasgroup" command line option is used, a faserver
     quota file with the fasgroup name appended will be con-
     tructed, copied to those hosts, but the quota on those
     faservers will NOT be reinitialized.  In this case, the ini-
     tialization must be handled by the mergefasquotas command.

Notes:

     Some machines mount their file sytems from other machines,
     so it is important to run this program in the right place.

     Manually changing quota values in the .../users file will
     only have a temporary effect for entries flagged as "spon-
     sor-math".  Such entries are updated automatically by the
     account updates run from the accounts-master machine.

Files Used:

     /etc/passwd
     /software/accounts/data/users
     /software/accounts/config/regional/fashosts
     /software/accounts/config/regional/rquotahosts

Copyright:

     Copyright (C) 1989, 1998, MFCF, University of Waterloo.

mkstudents command

NAME

     mkstudents - process the registrar's student file

SYNOPSIS

     mkstudents     [-g] [term]

     Options:
     g    - Keep grads
     term - term to be processed (eg S86)

DESCRIPTION

     Mkstudents adds and deletes students on Unix machines with
     appropriate updates to the USERS source file, the PASSWD
     source file, the GROUP source file and the home directory to
     conform to the current state of the students file.

     A list of course names that deserve VAX/UNIX accounts is
     required as the file Courses.

     This is the last in the series of student accounts mainte-
     nance programs. It should not be run directly by naive
     users.  Use add_all from the master machine instead.

FILES

     /usr/accounts/data/Courses
     /usr/accounts/data/students
     /usr/accounts/logs/change
     /usr/accounts/logs/mkstud
     /usr/accounts/standard/student/home/*
     /etc/passwd
     /etc/group
     /etc/users
     /u/USERID

SEE ALSO

     regtape(8), add_all(8), mkmatch(8), mkstuds(8), mkpw(8)

BUGS

     Mkstudents does not rebuild any dbm files.

mkstuds command

NAME

     mkstuds - process the registrar's student file

SYNOPSIS

     mkstuds   [-g] [-h home] [-P pwdfile] [-U usrfile] [term]

     Options:
     -g   delete grads (normally they are not deleted)
     -h   home filesystem
          default: /u[0-9]*  selected for maximum free space
     -P   flag next option as the name of the passwd file
          default: /etc/passwd, /etc/ypsrc/mad/passwd
     -U   flag next option as the name of the users file
          default: /etc/users,  /etc/ypsrc/mad/users
     term select accounts for semester 'term' of form 'S87'
          if not interactive a bad or missing term is an error,
          if interactive the program will prompt for input.

     Note: the users:type field is preset to xystudent[-zzzz] for
     student accounts where x={u,g}, y={h,m,d,x} and
     zzzz={special,wait,ta}.
     The tag student is mandatory as it is used for identifica-
     tion.

DESCRIPTION

     Mkstuds adds and deletes students on Unix machines by making
     appropriate updates to the USERS file, and the PASSWD file
     to conform to the current entries in the file
     /usr/accounts/data/students.

     A list of course names with quotas that are to be given Unix
     accounts on any particular machine is required in the file
     /usr/accounts/data/Courses.

     The actual PASSWD and USERS file should not be updated
     directly.  Rather the output from mkstuds (default: pwd,
     usr) should be installed with mkmerge to insure no conflicts
     occur and the appropriate directories and quotas are
     created.

     This is the last in the series of student accounts mainte-
     nance programs.

FILES

     /usr/accounts/data/Courses
     /usr/accounts/data/students
     /usr/accounts/data/pwd
     /usr/accounts/data/usr
     /usr/accounts/logs/change
     /usr/accounts/logs/mkstud
     /usr/accounts/standard/student/home/*
     /etc/users
     /u[0-9]*/USERID

SEE ALSO

     regtape(8), add_all(8), mkmatch(8), mkusers(8)

BUGS

     Bugs?

mkusers command

NAME

     mkusers, mkmerge - merge commandline or file data to update
     and create user accounts

EXAMPLE

     mkusers userid

     You probably don't really want to use any of the other
     options.

     Though maintained by us, this program is no longer used by
     MFCF or CSCF.

SYNOPSIS

     mkmerge [ -a ] [ -e ] [ -f ] [ -m ] [ -u[u] ]
           [ -l uidlen ] [ -k num_fs ] [ -P passwd ] [ -U users ]
           pwd_merge usr_merge

     mkusers [ -a ] [ -e ] [ -f ] [ -m ] [ -u[u] ]
           [ -l uidlen ] [ -k num_fs ] [ -P passwd ] [ -U users ]
           [ -p 'student'|'batch'|password ] [ -c comment ]
           [ -g group ] [ -h home ] [ -s shell ] [ -t type ]
           [ -q quota ] [ -i imagen ] [ -r resource ]
           [ -n 'fullname' ] [ -v vmid ] [ -b vmbillcd ]
           userid:sponsor ...

     where
     -m   - do *not* run mkpw after update,
            normally one rebuilds the passwd dbm to install changes
     -a   - add-only, do *not* update existing users,
            ie create an account, but do nothing if it already exists
     -e   - existing accounts only, do *not* create new users,
            ie update info fields for existing accounts only
     -f   - force finger info to be overidden by the update,
            normally values for active users are retained
     -u   - verify mode, do *not* update active files or logfile
            -uu, update active files, do *not* create home_dirs etc.
     -P   - flag: next option is to be used as active passwd filename
            also turns off creation of home_dirs, quota updates etc.
            default: /etc/passwd, /etc/ypsrc/mad/passwd (SUN domains)
     -U   - flag: next option is to be used as active users filename
            also turns off creation of home_dirs, quota updates etc.
            default: /etc/users,  /etc/ypsrc/mad/users  (SUN domains)
     -p   - flag: next option is the password or one of the keywords
            ('student','batch')
            default: '*No*Password*' unusable password
     -c   - flag: next option is a comment inserted into us_type
            (see mkstuds for valid student classes xystudent-zzzz)

     the remaining options can be set in /software/accounts/data/standard/stdopts
     -l   - maximum userid length
            default: UIDLEN (pre-programmed constant, eg 12)

     -g   - flag: next option is a valid group name in /etc/group
            default: 'other'
     -h   - flag: next option is the home directory or filesystem/,
            default: /u[0-9]*/userid  (selected by max freespace)
     -k   - count of home filesystems over which to spread users,
            default: 0 (don't spread, use maximum free space instead)
     -s   - flag: next option is the users shell
            default: /bin/csh
     -t   - flag: next option is the type of user, used to select
            initial .dotfiles from /software/accounts/data/standard/{type}
            default: 'other'
     -q   - flag: next option is the disk soft quota,
            the hard quota is computed as 120% of the soft quota
            use a quota of 0 to indicate that no quota is desired
            default: 1000 disk blocks
     -i   - flag: next option is the imagen pagelimit
            default: 0    no imagen access
     -r   - flag: next option is the dollar resources (not used)
            default: -1   unlimited
     -n   - flag: next option is usually 'fullname',
            a comment field for finger information
            default: ""  (mandatory on some systems - eg Eng)

     the next options are activated by placing an entry in stdopts
     -v   - flag: next option is a VM id number (dcsu)
            default: (mandatory entry)
     -b   - flag: next option is a VM billcode  (dcsu)
            default: (mandatory entry)
     -d   - flag: next option is a Sun domain (not used)
            default: 'mad' (maintenance and development)

     userid:comment - the userid string, and an optional comment
            inserted into the us_payment field. If a keyword has
            been given for a password, then the actual password
            is taken from this comment field. Usually this field
            gives the sponsor or reason for the account.
            (For MFCF students, this is the student number).

DESCRIPTION

     Mkusers creates accounts or updates accounts info for one or
     more users as specified by the selected options and/or cor-
     responding system defaults.

     The entries are built in memory and merged with the active
     system files as documented in mkmerge below.

     Mkmerge merges information contained in the passwd- and
     users-formatted files pwd_merge and usr_merge with that in
     the active or indicated files, and carries out all appropri-
     ate system tasks to update or create new users as required.
     Updates to the merge entries are written back out to the
     merge files so they reflect the actual active account after
     merging (For example, the actual value of the uid number
     used in creating the account will be returned).

     The vmid and vmbillcd options are local options used only on
     WatDcsu.

NOTE

     Consult your local accounts person for administration prac-
     tices in specifying information and commentary fields.

     The presence of a null string ("") in the standard options
     file /software/accounts/data/standard/stdopts makes the cor-
     responding option mandatory.

     The format of the stdopts file is:
         [     keyword = value  [     keyword = value  [     ...
     where current keywords are {umask, group, home, shell, type,
     name, quota, impages, dollars, vmid, vmbillcd, domain}.

CONFIGURATION OPTIONS

     The directories "/software/accounts/config/*/init_home" con-
     tain templates for new home directories.  They are copied
     into place in the standard xhier configuration order (i.e.
     share, arch, admin, regional), with the last found instance
     of any file being the one used.

     For backward compatibility, if the directory "/soft-
     ware/accounts/data/host/standard" exists, it alone will be
     used to do the initialization.  Administrators are encourage
     to remove this directory and to use the regional configura-
     tion instead.

     Note that the copying is done by following symbolic links,
     not copying them.  This means that one cannot initialize
     symbolic links in home directories.

FILES

     /etc/passwd                        the password file itself
     /etc/ptmp                          the password lockfile
     /software/accounts/data/users      local additions to passwd
     /u/username                        user home directory
     /u[0-9]+/username                        ditto
     /software/accounts/data/standard   default options
     /software/accounts/config/*/init_home default home directory
                                        templates and options
     /software/accounts/data/host/standard local overrides
                                        of default (deprecated)
     /u[0-9]/quotas                     system quota entries
     /software/accounts/logs/change     log file

SEE ALSO

     accounts_admin(i), rmusr(8), undelete(8), edquota(8),
     vipw(8), add_all(8), .login(5), .profile(5)

orphan command

Name:

     orphan - walk a directory tree looking for unowned files

Synopsis:

     orphan [+NFS] [directory]...

Description:

     Orphan walks directory trees looking for files whose uid or
     gid is no longer in the passwd or group file.

     If the userid "orphan" exists, any owner-orphaned files are
     adopted by that userid.  Otherwise they are left as orphans.

     If the group "orphan" exists, any group-orphaned files are
     adopted by that group.  Otherwise they are adopted by group
     "none".

     If the userid "delgroup" exits, any entries in the group
     file that have that userid as a member will be ignored.
     This allows one to mark a group for removal and let orphan
     claim all files that might be in that group, before actually
     removing the group entry from the file.  Not using this
     method, or removing the entry before the files are found
     could cause problems if another group entry is added with
     the same gid, as any existing files will suddenly and inap-
     propriately become owned by that group.

     The groups "everyone", "other", or "users" are checked for
     existence in that order and the first one found is treated
     specially.  For security, anything in that group is changed
     to be in group "none".

     Any files owned by the userids "delgroup", "help", "user-
     home", or "who" will be claimed by orphan, since these spe-
     cial-purpose userids are not intended for file ownership.

     It does not follow symlinks or NFS mounted file systems.
     When the NFS mounted filesystems can be checked by using the
     +NFS option, but in that case non-NFS filesystems will be
     ignored.

     While walking a tree, it will skip any paths (which must
     begin with "/") contained in the decomment(1)able file
     "/software/accounts/config/local/orphan_ignore".  If one of
     these roadblock paths contains a symlink, it will be treated
     as if it were its target.  (See "Note" below.)

Configuration:

     This program is automatically run by an entry in the
     crontab, once examining all non-NFS filesystems, and once
     examinining any NFS filesystems named in "/soft-
     ware/accounts/config/local/orphan_nfs".

Note:

     Because the roadblocks are implemented using device and
     inode numbers, if the "orphan_ignore" file contains
     "/one/two" and orphan is invoked as "orphan /one/two/three",
     this tree will not be ignored since the roadblock will never
     be encountered.

     Similarly, any "orphan_ignore" path that contains a symlink
     will use the device and inode numbers of the target.  E.g.
     if "/one/two -> /eight/nine/ten" then roadblocks "/one/two"
     and "/eight/nine/ten" will have the same effect, as will
     "/one/two/three" and "/eight/nine/ten/three".

See Also:

     accounts-config(7)

Copyright:

     Copyright (C) 1994, MFCF, University of Waterloo.

rmallusr command (VERY IMPORTANT)

NAME

     rmallusr - do final removal of deleted userids and their
     files.

SYNOPSIS

     rmallusr

DESCRIPTION

     rmallusr finds all userids in the passwd file that have a
     "/xhbin/Deleting*" login shell and completely removes them
     from the host.  This program normally runs from the crontab
     on the 1st of each month.

     Deleted userids are removed from /etc/passwd, /etc/group,
     and /software/accounts/data/host/users.

     All home directories under "/u/.", "/u[0-9]/.",
     "/backup`absolute /u/.`", "/backup`absolute /u[0-9]/.`", and
     all substructure are removed.

     All files owned by the deleted userids anywhere under
     "/u/.", "/u[0-9]/.", "/backup/.", and "/usr/spool/."  are
     removed.

     All remaining files owned by the deleted userids are
     reported.

FILES

     Log files are left under "/software/accounts/logs/.".

BUGS

     Deleted userids in mailing lists or aliases are detected,
     but not removed.

     The program is an sh script that makes too many assumptions
     about portability and its own abilities.

rmclean command

Name:

     rmclean - clean out files for deleted users on regional
     clients

Synopsis:

     servers/rmclean

Description:

     rmclean is normally called by rmallusr(8) during month-end
     account cleanup.  It runs on each regional client, cleaning
     up everything belonging to about to be deleted accounts.

     e.g. removing (or chowning to "orphan") filesystem entries,
     removing crontab entries, and killing processes.

Options:

     None.

Files Used:

     "/software/accounts/data/temp_regional/delete_uids"
     "/software/accounts/data/temp_regional/delete_userids"

Copyright:

     Copyright (C) 2003, MFCF, University of Waterloo.

rmusr command

NAME

     rmusr - remove user accounts

SYNOPSIS

     rmusr userid

DESCRIPTION

     Rmusr is used to disable an account and flag it for deletion
     given a userid.  It simply calls chsh (ypchsh) to install an
     /xhbin/Deleting shell.  The account is finally deleted on
     the 1st of the month, so be aware that removing an account
     on the last day of a month means that it will actually dis-
     appear very soon.

FILES

     /etc/passwd
     /etc/shells_system
     /usr/accounts/logs/change

SEE ALSO

     undelete(8), rmallusr(8)

setpasswd command

NAME

     setpasswd - change some fields in the passwd file.

SYNOPSIS

     setpasswd -help

     This command has been superseded by password(1), chfn(1),
     and chsh(1).

DESCRIPTION

     T.B.A.

stripnames command

Name:

     stripnames - strip entries and members from
     /etc/{group,passwd} type files

Synopsis

     stripnames entry [Input=-] [FieldNumber=0] [Name-
     File=/dev/null] [[name=]null]* [IfMember=killme]
     stripnames member [Input=-] [FieldNumber=0] [Name-
     File=/dev/null] [[name=]null]*

     [Input=-]
          Path of input file to be stripped.  Default is standard
          input.

     [FieldNumber=0]
          Number of the colon-separated field containing the mem-
          ber names.  A field number of 0 indicates that there is
          no such field.

     [NameFile=/dev/null]
          Path of a decommentable file containing names, one per
          line, to be stripped from the input file.

     [[name=]null]*
          Names to be stripped from the input file.  May be used
          with or instead of "NameFile".

     [IfMember=killme]
          For the "stripnames"entry command, the entry will be
          stripped only if the given name is in the list in field
          position "FieldNumber".

Examples:

          # Remove groups "curly", "larry", and "moe" from /etc/group,
          but only if "userhome" is a member of the group:
          % cat /etc/group \
          | stripnames entry fn=4 im=userhome curly larry moe \
          >/etc/group.lock

          # Remove userids "curly", "larry", and "moe" from /etc/group:
          % cat /etc/group \
          | stripnames member fn=4 curly larry moe \
          >/etc/group.lock

          # Remove userids "curly", "larry", and "moe" from /etc/passwd:
          % cat /etc/passwd \
          | stripnames entry curly larry moe \
          >/etc/ptmp

Description:

     stripnames is invoked with one of two subcommands.

     The member subcommand causes all occurences of the given
     "name"s to be removed from the comma-separated list in the
     given "FieldNumber" colon-separated field.

     The entry subcommand causes all lines whose first colon-
     separated field is the same as any of the given "name"s to
     be deleted.  If the "IfMember" option is used, then the
     lines will be deleted only if the give member name is a mem-
     ber of the comma-separated list in the given "FieldNumber"
     field.

Copyright:

     Copyright (C) 1999, MFCF, University of Waterloo.

undelete command

NAME

     undelete - restore user accounts deleted by rmusr

SYNOPSIS

     undelete userid

DESCRIPTION

     Undelete is used to renable an account that has been flagged
     for deletion but has not yet been deleted.  It simply calls
     chsh (ypchsh) to change an /xhbin/Deleting shell.

FILES

     /etc/passwd
     /etc/shells_system
     /usr/accounts/logs/change

SEE ALSO

     rmusr(8), rmallusr(8)

xhier_admin command

     [OBSOLETE: use `hostin group=admin_master`]

Name:

     xhier_admin - return the name of the xhier admin server

Synopsis:

     xhier_admin_server

Description:

     xhier_admin_server checks the local machine's configuration
     and reports the name of its xhier admin server.

Files Used:

     /software/xhier/config/local/allowed-types

Bugs:

     This command doesn't belong in the accounts package.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

xhier_admin_server command

     [OBSOLETE: use `hostin group=admin_master`]

Name:

     xhier_admin - return the name of the xhier admin server

Synopsis:

     xhier_admin_server

Description:

     xhier_admin_server checks the local machine's configuration
     and reports the name of its xhier admin server.

Files Used:

     /software/xhier/config/local/allowed-types

Bugs:

     This command doesn't belong in the accounts package.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

xhier_regional_clients command

An understanding of the regional clients concept is important for understanding the basis of much of the old accounts maintenance system.

     [OBSOLETE: Superseded by `hostin group=regional_clients`]

Name:

     xhier_regional_clients - return the name(s) of all clients
     in the region

Synopsis:

     xhier_regional_clients

Description:

     xhier_regional_clients checks the local machine's configura-
     tion and reports the names, if any, of all clients in the
     xhier region.  The regional server is not included in this
     list.

Files Used:

     /software/accounts/data/regional-clients/<hostname>

Bugs:

     The returned hostnames are the same as that returned by the
     hostname(1) command on each client, and as such may or may
     not be fully qualified with the domain name.

     The information is reliable only if the accounts package is
     installed on each client in the region.

     This command doesn't belong in the accounts package, but for
     some unknown reason the xhier package doesn't provide this
     basic xhier information.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

xhier_regional_server command

     [OBSOLETE: use `hostin group=regional_server`]

Name:

     xhier_regional_server - return the name of the xhier
     regional server

Synopsis:

     xhier_regional_server

Description:

     xhier_regional_server checks the local machine's configura-
     tion and reports the name of its xhier regional server.

Files Used:

     /software/accounts/data/regional-server/<hostname>

Bugs:

     The returned hostname is the same as that returned by the
     hostname(1) command on the server, and as such may or may
     not be fully qualified with the domain name.

     This command doesn't belong in the accounts package, but for
     some unknown reason the xhier package doesn't provide this
     basic xhier information.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

accounts administration policy

Name

     Accounts_Admin - Account Administration Policy

Terminology:

     A "userid" is a name used to identify a computer user, inde-
     pendent of its existence on any particular machine.

     An "account" is used to identify a particular instance of a
     userid on an particular machine.  It is typically repre-
     sented in the form "userid@host".

Userid Creation:

     For each administration, there will be one central registry
     containing all userids issued by that administration.

     No one should ever create (an account with) a new userid
     without first registering the userid.

     Details about the user, such as full name, UW student num-
     ber, employee number, SIN, association with UW, etc. will be
     required.  This information is especially important for
     identifying the user when requests for passwords or other
     account changes are made.

     Note that the administration may issue a different userid
     than the one requested, either because the requested userid
     has already been assigned to another user or because the
     requested userid does not conform to the administration's
     standards.

     In the case of the MFCF administration, all userids are reg-
     istered in the accounts-userids package on the host "math".
     Requests for new userids or questions about existing userids
     should be mailed to "accounts@math".

Passwords:

     If more than one person knows something, it isn't a secret.
     Thus, a good rule for security is that any password should
     never be known by more than one person.  In particular, when
     creating communal accounts, such as cs123, one should not
     give an explicit password to the account, but use the
     account's ".rhosts" file to grant access to specific users.

Account Accounting:

     No one should ever create an account on any machine without
     notifying the administration of the fact and including
     details as to who is sponsoring the account.

     In the case of the MFCF administration, this information
     should be mailed to "accounts@math".

Warning:

     Accounts that were not created following these rules may be
     disabled or removed by the administration (or by automated
     software) without warning.

Summary:

     In general it is always best to ask the central administra-
     tion to create accounts rather than attempting it oneself.

Account Creation:

     No one should ever create an account on any machine without
     first verifying that the userid is already registered to the
     same person for whom the account is intended.

     In the case of the MFCF administration, requests for new
     userids or other related questions should be mailed to
     "accounts@math".

     It is not generally safe to assume that a userid listed by
     the uwdir(1) command is necessarily the standard userid for
     your administration (in particular it often isn't for MFCF.
     It is generally safe to assume that if an account on one of
     the machines listed by "hostin group=mfcf_accounts", will
     have an MFCF-standard userid, but be sure you know the full
     form of the userid (e.g. the last component of the home
     directory shown by finger(1)).

     If you are going to manage your own accounts, you must be in
     group "accounts", and should set your search rules with the
     showpath(1) command to include the "accounts:guru" type.
     Here is a summary of some commands you will likely want to
     use:

     # mail accounts@math
          If you have any doubts that the userid you are about to
          use is the standard userid assigned to the person or
          organization you are creating it for, please ask first
          to make sure.

     # mkusers full-length-userid
          This creates the account and initializes the home
          directory.  Be sure to use the full length userid (i.e.
          not a truncated form) so that mail and other programs
          will recognize the account properly.  In any further
          commands, the userid may be entered in a shorter form
          so long as it is at least 8 characters long.

     # password +r userid
          This sets the user's login password to a randomly gen-
          erated string.  The user can change it to something
          else later using the "password" command without any
          arguments.

     # edit_rhosts userid
          This lets you create and change the user's ".rhosts"
          file.

     # edit_forward userid
          This lets you create and change the user's ".forward"
          file.

     # rmusr userid
          Once the account is no longer needed, this command will
          change the login shell to prevent its further use.  At
          the end of the month, the program rmallusr(8) will
          remove the "/etc/passwd" entry and clean up the home
          directory, mail spool, /etc/group, etc.

     # undelete userid
          If you change your mind before the end of the month,
          this will reset the user's login shell.

See Also:

     userids(i),
     mfcf-policy(i),

Copyright:

     (C) 1992, 1996, MF, University of Waterloo

groups information

Name:

     groups - how to use groups on MFCF supported machines.

Description:

     When your new account is created, a group is assigned to
     your home directory (by default group "none") and one or
     more groups are assigned to your userid (by default group
     "everyone").  Some machines are configured to assign a per-
     sonal group (bearing the same name as the userid) to each
     account.  In that case, this group will be used as both the
     login group and the home directory group.

     All files created directly under a directory will automati-
     cally inherit the group associated with that directory.
     Thus if you do nothing special, all your files and sub-
     directories will end up in group "none".  (Note that this
     isn't true if you run commands on IBM AIX or other SysV-
     semantic machines.)  You may use the chgrp(1) command to
     change the group associated with a file or directory to
     something else.  This will not affect any files already
     under the changed directory, but any files created there in
     the future will inherit this new group.  You may of course
     only change the group of a file that you own, and only to a
     group to which you belong (or to group "none", a group to
     which no user belongs).

     Normally, you will only belong to the one group "everyone",
     and all of your files will belong to the one group "none",
     so you don't need to be worry about groups.

     In some cases, you (i.e. your userid) will be assigned to
     more than one group.  For instance you might be put into
     group "source" so that you may be permitted to read system
     source files.  This is done by having the source directory
     owned by group "source", and that directory granting read
     and execute permissions to its group, but no permissions to
     others.  Files and directories under that directory should
     be created with general read permissions and not in group
     source, but because of the roadblock in the parent directory
     they will only be accessible by those in group source.

     Similarly, for a class project you and your partner(s) may
     have a special group, say "cs123_45", created for you.  What
     you would both then do is to create directories under each
     of your own accounts, put those directories into that new
     group, and change the permissions so that only you and your
     partner may use that directory.
          % mkdir  $HOME/cs123_45
          % chgrp  cs123_45  $HOME/cs123_45
          % chmod  770  $HOME/cs123_45    (or use ug=rwx instead of 770)
     Now, both of you may freely create or remove files or direc-
     tories under that directory, even though it might not be
     under your own home directory.  No one else will even be
     able to find so much as the names of the files though.

     Note that for courses you are officially registered in,
     course directories will be automatically created under your
     home directory.  A command, fixclassperms(1), allows course
     instructors to change the permissions on these directories
     to allow them to access your files for marking.

     In order for the files you create under such a directory to
     be readable by others in your group, you must have your
     "$UMASK" environment variable set to something like 022.
     This will allow others in your group to read the files, but
     not to change them.  More likely though, you will want them
     to be able to change them as well, so you would set your
     mask to 002.  In that case you would probably put the com-
     mand "umask 002" into your "$HOME/.cshrc" file, so that all
     files that you ever create will allow writing for members of
     their group, but not for anyone else.

See Also:

     .cshrc(5):  Initial shell configuration
     umask(1):  Determine permissions of newly created files
     mkdir(1):  Create a new directory
     chgrp(1):  Change the group of a file or directory
     find(1):  Search for files under a directory
     ls(1):  Show ownership etc. of files
     fixclassperms(1):  For TAs: resets groups and permissions
     classgroup(1):  For TAs: subshell to get around NFS problems

Copyright:

     (C) 1988, 1996, MFCF, University of Waterloo.

check_userids command

Name:

     check_userids - check Userids file.

Synopsis:

     check_userids

Description:

     check_userids checks that the Userids file is valid.

Files

     /software/accounts-userids/data/Userids

Bugs

     You cannot specify an alternate file to check.

Copyright:

     Copyright (C) 1991, MFCF, University of Waterloo.

id-to-userid command

Name:

     id-to-userid - filter to map ID numbers to userids in colon-
     separated fields

Synopsis:

     id-to-userid [Id=1] [Userid=0]

Examples:

          % cat input
          one:two:71212246:four:five
          % id-to-userid <input id=3
          one:two:rbutterworth:four:five
          % id-to-userid <input id=3 u=3
          one:two:rbutterworth:71212246:four:five
          % id-to-userid <input id=3 u=-4
          one:two:71212246:rbutterworth:five
          % id-to-userid <input id=2
          one:?:71212246:four:five
          % id-to-userid <input id=3 u=10
          one:two:71212246:four:five:::::rbutterworth

Options:

     [Id=1]
          Field number (origin 1) of the input ID number.  IDs
          can be watcard numbers (71212246), uwdir numbers
          (P-35580), etc.

     [Userid=0]
          Field number (origin 1) of the output userid.  The
          default, "0", means to replace the ID field.  A nega-
          tive number means to replace the specified field.  Oth-
          erwise an addition field is inserted before the given
          field.

Description:

     id-to-userid reads records of colon-separated fields from
     standard input and writes the records to standard output,
     replacing or inserting a field containing the userid that
     corresponds to the given "Id" field number.

     As processing the Userids database requires significant
     overhead, when multiple IDs need to be evaluated it is best
     to provide them all to a single invocation of this command
     rather than calling it once for each ID.

Files:

     /software/accounts-userids/data/Userids

Copyright:

     Copyright (C) 2006, MFCF, University of Waterloo.

isuser command

Name:

     isuser - check if a user id is in a list of ids

Synopsis:

     isuser known_id id_1 id_2 id_3 ...

Example:

     if ( { isuser $user1 91999123 joe 11119876 } ) then
          echo $user1 matched at least one of the other ids
     endif

Description:

     isuser looks in the "Userids" file and finds all knows ids
     and userids for each of the ids on the command line.

Returns:

     If any of the ids for the first argument match any of the
     ids for any of the other arguments, the function exits 0.
     Otherwise it exits 1.

Files Used:

     /software/accounts-userids/data/Userids

See Also:

     realuser(1), sameuser(1), truncuser(1)

Copyright:

     Copyright (C) 1996, MFCF, University of Waterloo.

update_userids command

Name:

     update_userids - update the Userids database with uwdir data

Synopsis:

     servers/update_userids

Description:

     update_userids

     This program normally runs from the crontab.

     It uses uwdir_update(8) to merge the latest dump of the
     UWdir database with the Userids database.

     Detected changes are logged, and the cron entry mails the
     signifcant parts to "accounts@math".

Files:

     watserv1:/sagroup/UWdir-II/Extract /software/accounts-
     userids/data/Userids /software/accounts/logs/userids_update

See Also:

     uwdir_update(8), check_userids(8)

Copyright:

     Copyright (C) 2002, MFCF, University of Waterloo.

uwdir_update command

Name:

     uwdir_update - merge UWdir data into the Userids database

Synopsis:

     servers/uwdir_update
     [Extract=/software/accounts-userids/data/work/Extract]
     [Userids=/software/accounts-userids/data/Userids]

Options:

     Extract=/software/accounts-userids/data/work/Extract
          Dump of UWdir data to be merged.

     Userids=/software/accounts-userids/data/Userids
          Master Userids database.

     The options are provided mostly for debugging purposes, and
     are not normally needed.

Description:

     uwdir_update is intended to be run by another program (nor-
     mally from the crontab).  It updates the master Userids
     database with IST uwdir data, reporting errors and inconsis-
     tencies.  IST records with errors are ignored, while serious
     MFCF errors cause abnormal termination.

     The name of the updated file will be the same as the input
     file, but with a ".new" suffix appended.

Output:

     Serious errors with the program itself are reported on
     stderr, as is the message indicating that fatal problems
     were discovered in the input data.

     All other problem reports appear on standard output, the
     most serious being prefixed with "***", and the least impor-
     tant being prefixed with "+++".  In addition to the wording
     shown below, most messages will also indicate the text in
     which the problem was found, and mention the line number and
     file name where it was encountered.

     "*** Fatal: illegal missing newline"
          Badly formatted input data.

     "*** Fatal: illegal id number"
          The id number doesn't match any of the known id-number
          formats.

     "*** Fatal: illegal userid"
          The userid doesn't meet the standard for userids.

     "*** Fatal: mfcf record repeats id"
          The same id appears twice in the same record.

     "*** Fatal: two mfcf records with same id"
          The same id appears in two different records.

     "*** Fatal: mfcf record repeats userid"
          The same userid appears twice in the same record.

     "*** Fatal: two mfcf records with same userid"
          The same userid appears in two different records.

     "*** Fatal: file got shorter"
          Something strange happened.

     "Error: id xxx matches mfcf's userid1 and userid2"
          An IST record has ids that match two mfcf records.

     "Error: id xxx matches ist's userid1 and userid2"
          An mfcf record has ids that match two IST records.

     "Error: userid xxx matches mfcf's id1 and id2"
          An IST record has a userid that matches two mfcf
          records.

     "Error: userid xxx matches ist's id1 and id2"
          An mfcf record has a userid that matches two IST
          records.

     "Error: userids differ for xxx ist=yyy mfcf=zzz"
          An user has different uwdir and mfcf userids.

     "Error: userids match but no common ids"
          A userid occurs in both databases, but the entries have
          no other ids in common, and so might be for different
          users.

     "IST error: student id number"

     "IST error: HR id number"

     "IST error: userid"

     "IST error: other id"
          The ID doesn't match any of the known id formats.  (IST
          records all kinds of ids in the same namespace.)

     "IST error: ist record repeats id"
          The same id appears twice in the same record.

     "IST error: two ist records with same id"
          The same id appears in two records.

     "IST error: ist record repeats userid"
          The same userid appears twice in the same record.

     "IST error: two ist records with same userid"
          The same userid appears in two records.

     "+++ changed %s: old-name -> new-name"
          A user's name has changed.

     "+++ removed privacy for xxx"

     "+++ added privacy for xxx"
          A user's privacy request has changed.

     "+++ added xxx to yyy"
          An existing userid entry got an additional id number.

     "+++ added [new userid entry]"
          A new userid entry was added to the Userids database.

     "+++ can't add xxx: no id number"
          A new userid doesn't have a valid id number.

Handling problems:

     Fatal errors mean that no update happened.  The cause needs
     to be corrected as soon as possible.

     Non-fatal Errors affect only individual records.  The cause
     should be investigated and corrected to allow those individ-
     ual updates to proceed, but this isn't as urgent (except
     possibly for the individuals affected) as the rest of the
     updates are still processed normally.

     IST errrors generally require corrections to the UWdir
     database itself.  These are even less urgent, as they simply
     prevent bad data from entering the Userids database.  Note
     that IST doesn't consider many of them to actually be errors
     (e.g. two records with the same id), in which case MFCF must
     make the corrections.

     The most commonly seen problems are:

     "Error: id xxx matches mfcf's userid1 and userid2"

     "Error: userid xxx matches mfcf's id1 and id2"
          One IST record matched two MFCF records.  This usually
          means that the two MFCF records should be merged (after
          determining which userid is the correct one to retain).

     "Error: id xxx matches ist's userid1 and userid2"

     "Error: userid xxx matches ist's id1 and id2"
          One MFCF record matched two IST records.  This usually
          means that the two IST records should be merged.  It is
          best to let IST know about it so they can investigate
          further before merging their records.

     "Error: userids differ for xxx ist=yyy mfcf=zzz"
          A user has different userids in the two databases.
          This can be caused by:

          -    the user's existing uwuserid changed, so change
               the userid in the Userids database.

          -    the user lost their uwdir entry (or never had one)
               and their recently created entry was given a dif-
               ferent userid.  Determine which of the two userids
               is the appropriate one to use, and change the
               Userids or UWdir database accordingly.

     "Error: userids match but no common ids"
          A userid appears in both databases, but the software
          can't tell that they are for the same person.  These
          problems must be investigated by hand.  If it turns out
          that they are for the same person, simply add one of
          the UWdir ids to the Userids entry to identify them.
          It they are for different people, it is usually the
          case that the Userids entry is old and no longer worth
          preserving, so simply remove it.

See Also:

     update_userids(8), check_userids(8)

Copyright:

     Copyright (C) 2002, MFCF, University of Waterloo.

.classlist command

Name:

     classlist, .classlist - list of students registered in a
     class.

Synopsis:

     /u/<classname>/.classlist

     Supported on undergrad.math only.

Format:

     The file contains the following colon-separated fields, one
     per line.  Blank lines and lines beginning with a "#" char-
     acter may be ignored (e.g. use decomment(1) to extract the
     data).

     Id Number
          the student id number associated with the userid.

     Userid
          the standard userid assigned to the account.

     Name the student's family name, a comma, and any given
          names.  Some names might be prefixed with an asterisk
          (*).  In such cases, University policy requires that
          these names not be made publicly available, and as such
          are restricted to internal administrative use only.  In
          particular this applies to setting finger information
          on machines, publishing email addresses, and producing
          any other form of directory.

     Lecture
          the lecture section that the student is registered in.

     Study
          the study field (i.e. department (sort of)) that the
          student is registered in.

     Plan the plan that the student is registered in.

     Group
          the group (i.e. faculty) that the student is registered
          in.

     Year the current year the student is registered in.

     Degree
          the degree the student is currently registered in.

     Initials
          the given initials of the student (as currently
          recorded by the Registrar).

     Family
          the student's family name.

     Status
          the student's status (R-registered, E-pre-registered,
          W-withdrawn).

     Time the student's attendance (P-partime, F-fulltime).

     Session
          the session that the student is registered in.

     Sections
          The section number given in the fourth field is for
          lecture ("lec") enrollment.  This lists that and all
          other sections in a comma separated list.  e.g.
          "lec=002,tut=101,tst=201".

     Other
          Additional fields may be added in the future without
          further warning, so do not write programs that rely on
          there being exactly the current number.

     In some unusual cases, e.g. for non-student or non-people
     accounts, fields such as "student id number" and "family
     name" might have completely different meanings.

Description:

     The information in these files is based on data provided to
     MFCF from the Registrar by Data Processing (and occasionally
     on other data).  The files are updated soon after new data
     becomes available, quite frequently at the beginning of each
     term and less frequently at the end.

     These files are not created for all classes, but only those
     for which the instructors have made explicit requests.

Access:

     The file for say class cs123 will be called
     "/u/cs123/.classlist" and will be owned by the userid
     "cs123" and the group "cs123".  Since id numbers are consid-
     ered confidential, the files do not have general read per-
     mission.  Typically the course instructors and TAs will be
     members of the group and will possibly be in the account's
     ".rhosts" file, which allows them to rlogin(1c) to the
     account.

Examples:

          #Print a list of names and userids, sorted by family name
          decomment /u/cs123/.classlist | cut -d: -f3,2 | sort

See Also:

     decomment(1), cut(1), cl2sc(1).

Bugs:

     For students registered in more than one department or fac-
     ulty, only one of their registrations will appear in the
     file.

Copyright:

     Copyright (C) 1992,1996,2000,2001 MFCF, University of Water-
     loo.

account_update command

Name:

     account_update - merge account information with /etc/passwd
     etc.

Synopsis:

     servers/account_update [+Groupcheck] [Update=-]
     [NewGroup=-] [NewPasswd=-] [NewUsers=-]
     [Group=/u/rbutterworth/test/group]
     [Passwd=/u/rbutterworth/test/passwd]
     [Users=/u/rbutterworth/test/users]

Description:

     account_update is normally invoked from sponsor_accounts(8).

     The Update data (defaulting to standard input) contains
     records with the following colon-separated fields: Userid
     (full, non-truncated), Name (typically "Family, Given"), ID
     (student id or employee id), UID (suggested number), and
     Classes (comma-separated list with format:
     "Name(diskquota;group,group,...)"), as described in
     "<accounts/resources.h>".

     Group is normally "/etc/group", Passwd is normally
     "/etc/passwd", and Users is normally "/soft-
     ware/accounts/data/users".

     The three resulting sets of output (by default standard out-
     put) are normally set to temporary files (e.g "/etc/ptmp")
     that are eventually moved to replace the originals.

     +Groupcheck causes the program to report any unsponsored
     group memberships.

     If there are any "/u#" directories, new home directories
     will be created under them, starting at one randomly chosen
     and cycling through them for each new home directory.  Oth-
     erwise home directories will be created under "/u".  If any
     potential home directory directory contains a file called
     ".ManualHomeDirectoryCreation", that directory will not be
     considered.

See Also:

     sponsor_accounts(8), /usr/include/accounts/resources.h

Copyright:

     Copyright (C) 1996 MFCF, University of Waterloo.

cl2sc command

NAME
  cl2sc - filter to convert a ".classlist" file into "sc" form

SYNOPSIS
  cl2sc

EXAMPLES
       cayley% cl2sc <~cs456/.classlist >list
       cayley% sc list

DESCRIPTION
  cl2sc is a filter that converts a .classlist file as produced by the
  accounts package in the home directories of course accounts into a file
  that the sc command will accept as input.  The output is sorted by surname,
  and then given names.  The spreadhseet columns defined are:
       Surname GivenNames StudentID Userid Division Section
  The titles for the columns are in row 0 of the spreadsheet.

FILES

  ~CourseNumber/.classlist
       - where class list files are kept.

SEE ALSO
  sc(1) - the spreadsheet that uses the output of this command.

BUGS
  It's not obvious that this is useful when a .classlist file is updated.

classgroup command

Name:

     classgroup - start a subshell in a class project group

Synopsis:

     classgroup groupnumber ['command and args']

Example:

     [201]% wmi
     cs123@cayley (Group everyone) on ttyub at /u1/cs123
     [202]% groups
     everyone ... cs123 ...
     [203]% classgroup 45
     1>[57]% wmi
     cs123@cayley (Group everyone) on ttyub at /u1/cs123
     1>[58]% groups
     everyone ... cs123 ... cs123_45
     1>[59]% exit
     [204]% /* Back where we started */

Description:

     The classgroup command is necessary on those systems that
     allow the class account to be in a very limited number of
     groups.

     If the caller is a class account (e.g.  "cs123"), and in
     group "classgroup", a subshell, using "/bin/csh" if the
     "$SHELL" environment variable is not set, will be started in
     the given numbered project group.

     Note that leading zeros are significant in the group number.
     "cs123_4" is not the same as "cs123_04".

See Also:

     fixclassperms(1)
     userinfo(1)
     groups(i)

Copyright:

     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

classlist command

Name:

     classlist, .classlist - list of students registered in a
     class.

Synopsis:

     /u/<classname>/.classlist

     Supported on undergrad.math only.

Format:

     The file contains the following colon-separated fields, one
     per line.  Blank lines and lines beginning with a "#" char-
     acter may be ignored (e.g. use decomment(1) to extract the
     data).

     Id Number
          the student id number associated with the userid.

     Userid
          the standard userid assigned to the account.

     Name the student's family name, a comma, and any given
          names.  Some names might be prefixed with an asterisk
          (*).  In such cases, University policy requires that
          these names not be made publicly available, and as such
          are restricted to internal administrative use only.  In
          particular this applies to setting finger information
          on machines, publishing email addresses, and producing
          any other form of directory.

     Lecture
          the lecture section that the student is registered in.

     Study
          the study field (i.e. department (sort of)) that the
          student is registered in.

     Plan the plan that the student is registered in.

     Group
          the group (i.e. faculty) that the student is registered
          in.

     Year the current year the student is registered in.

     Degree
          the degree the student is currently registered in.

     Initials
          the given initials of the student (as currently
          recorded by the Registrar).

     Family
          the student's family name.

     Status
          the student's status (R-registered, E-pre-registered,
          W-withdrawn).

     Time the student's attendance (P-partime, F-fulltime).

     Session
          the session that the student is registered in.

     Sections
          The section number given in the fourth field is for
          lecture ("lec") enrollment.  This lists that and all
          other sections in a comma separated list.  e.g.
          "lec=002,tut=101,tst=201".

     Other
          Additional fields may be added in the future without
          further warning, so do not write programs that rely on
          there being exactly the current number.

     In some unusual cases, e.g. for non-student or non-people
     accounts, fields such as "student id number" and "family
     name" might have completely different meanings.

Description:

     The information in these files is based on data provided to
     MFCF from the Registrar by Data Processing (and occasionally
     on other data).  The files are updated soon after new data
     becomes available, quite frequently at the beginning of each
     term and less frequently at the end.

     These files are not created for all classes, but only those
     for which the instructors have made explicit requests.

Access:

     The file for say class cs123 will be called
     "/u/cs123/.classlist" and will be owned by the userid
     "cs123" and the group "cs123".  Since id numbers are consid-
     ered confidential, the files do not have general read per-
     mission.  Typically the course instructors and TAs will be
     members of the group and will possibly be in the account's
     ".rhosts" file, which allows them to rlogin(1c) to the
     account.

Examples:

          #Print a list of names and userids, sorted by family name
          decomment /u/cs123/.classlist | cut -d: -f3,2 | sort

See Also:

     decomment(1), cut(1), cl2sc(1).

Bugs:

     For students registered in more than one department or fac-
     ulty, only one of their registrations will appear in the
     file.

Copyright:

     Copyright (C) 1992,1996,2000,2001 MFCF, University of Water-
     loo.

expire_accounts command

Name:

     expire_accounts - warn and/or disable expired accounts

Synopsis:

     expire_accounts

Description:

     expire_accounts looks at the "users" file for expired
     accounts (i.e. those marked as no longer having reason to
     exist), and each account that has exceeded the host's grace
     period (default 21 days) is disabled (currently the login
     shell is set to "/xhbin/Deleting").  Accounts are not dis-
     abled on Friday, Saturday, or Sunday though.

     A warning is mailed to each expired account the day after it
     expires, every 5 weeks after that, and every week during its
     last month of life.

Note:

     This command is not privileged but should be run as root.

Files Used:

     /software/accounts/data/users -- state of regional accounts
     /software/accounts/config/regional/grace -- set grace period

Copyright:

     Copyright (C) 1992,1999, MFCF, University of Waterloo.

fixclassperms command

Name:

     fixclassperms - fix the permissions on a student's course
     directory

Synopsis:

     fixclassperms userid

Description:

     The caller must be "root" or in the appropriate class
     group(s).  Note that course accounts are normally in their
     own group, but TA's and instructors are not normally in the
     course group unless they explicitly request it (since they
     are usually in the course's ".rhosts" file and so can use
     "rsh -l cs123 ..."  or "rlogin -l cs123 ...").

     The fixclassperms command determines which classes the given
     student is enrolled in, and modifies the group ownership and
     permissions on all the student's class directories (e.g.
     "/u/userid/cs123") to allow the files to be read by the
     course instructors but not by anyone else.

     For courses that use subgroups for group projects, (e.g.
     "/u/userid/cs488_03"), these subdirectories will also be
     given group write permissions.  Students should be warned to
     put their group projects under these directories and not
     under the general course directory to prevent the group per-
     missions from being changed incorrectly.

     Note that the class directories (e.g. cs123) are created
     automatically when the student enrolls in the course, but
     the group directories (e.g. cs123_45) must initially be cre-
     ated by the students.

See Also:

     userinfo(1)
     classgroup(1)
     groups(i)

Copyright:

     Copyright (C) 1993, 1997, MFCF, University of Waterloo.

link_homes command

Name:

     link_homes - create symlinks to home directories

Synopsis:

     link_homes [{+|-}NFS] directory

Description:

     link_homes creates symlinks to all the home directories in
     the /etc/passwd file that are under "/u#".

     Typically this is run as part of the accounts creation pro-
     cess, with the "directory" containing the new links being
     "/u".

     To avoid accidents, by default an error message will appear
     if the directory is nfs mounted.  The "+NFS" option causes
     an error unless the directory is nfs mounted, while the
     "-NFS" option causes the progam to silently exit if the
     directory is nfs mounted.

Configuration:

     The file "/software/accounts/config/local/link_homes" may
     contain default option flags (currently only "+NFS"), one
     per line.

Copyright:

     Copyright (C) 1992, 1998, MFCF, University of Waterloo.

mac_pw_sync command

Name:

     mac_pw_sync  - synchronizes passwords on a Mac with the cur-
     rent UNIX host

Synopsis:

     mac_pw_sync [+Debug] [hostname=]mac-hostname*

Description:

     mac_pw_sync fetches the accounts information from the speci-
     fied Macs, selects those entries with "/u/..." home directo-
     ries, replaces all but the home directory and  shell  fields
     with  the  corresponding  entries  on  the current host, and
     updates the Mac with the result.

     The +Debug flag displays the resulting update commands with-
     out actually executing them.

See Also:

     mac_to_passwd(8).

Copyright:

     Copyright (C) 2005, MFCF, University of Waterloo.

mac_to_passwd command

Name:

     mac_to_passwd - converts a Mac dump to /etc/passwd format

Synopsis:

     mac_to_passwd [no arguments]

Description:

     mac_to_passwd is a filter that takes the output of one or
     more instances of the Mac command "nicl . -read
     /users/USERID" on standard input and produces the equivalent
     "/etc/passwd" style data on standard output.

     Note that in addition to the usual passwd fields, the Mac
     version also includes three fields (class, change, and
     expire) between the gid and gecos fields.

Copyright:

     Copyright (C) 2005, MFCF, University of Waterloo.

ppp_dialup_update command (PRUNED)

Anything related to the ppp (telephone modem) type of resources was never used in recent memory.

ppp_update command (PRUNED)

Anything related to the ppp (telephone modem) type of resources was never used in recent memory.

sponsor_accounts command

Name:

     sponsor_accounts - update the sponsored accounts

Synopsis:

     servers/sponsor_accounts [+Force] [+GroupCheck]

Description:

     sponsor_accounts is normally invoked via an rsh from the
     accounts-master machine after it has first copied a list of
     sponsored accounts to the file "/soft-
     ware/accounts_client/data/sponsor_requests/accounts".

     If this update doesn't exist, or is the same as "/soft-
     ware/accounts_client/data/sponsor_requests/accounts.old", or
     if "/etc/passwd" is busy, the program exits with a message
     to that effect.  Specifying +Force will cause the program to
     continue even if the update is the same as the old state.

     The update is merged with the current "/etc/passwd",
     "/etc/group", and "/software/accounts/data/users" files
     (account_update).

     Then missing home directories are created (mkhomes), sym-
     links to home directories from under /u are updated
     (link_homes), and disk quotas are updated (mkquota).

     Finally, if "/software/accounts/config/regional/mkfinal" is
     decomment empty it is run to do anything extra that is spe-
     cific to this host.  Otherwise "/software/accounts/con-
     fig/admin/mkfinal" will similarly be tried.

See Also:

     account_update(8), mkquota(8), mkhomes(8), link_homes(8).

Copyright:

     Copyright (C) 1996, 2001, MFCF, University of Waterloo.

sponsor_aliases command

Name:

     sponsor_aliases - update the sponsored mail aliases

Synopsis:

     servers/sponsor_aliases [+Force]

Description:

     sponsor_aliases is normally invoked via an rsh from the
     accounts-master machine after it has first copied a list of
     sponsored mail aliases to the file "/soft-
     ware/accounts_client/data/sponsor_requests/aliases".

     If this update doesn't exist, or is the same as "/soft-
     ware/accounts_client/data/sponsor_requests/aliases.old", the
     program exits with a message to that effect.  Specifying
     +Force will cause the program to continue even if the update
     is the same as the old state.

     The update is put into the "/soft-
     ware/accounts_client/export/aliases" file.

     Then the package is reinstalled on all regional clients.

See Also:

     sponsor_accounts(8), account_update(8), mkquota(8),
     mkhomes(8), link_homes(8).

Copyright:

     Copyright (C) 2004, MFCF, University of Waterloo.

sponsor_ppp command (PRUNED)

Anything related to the ppp (telephone modem) type of resources was never used in recent memory.

usergroups command

Name:

     usergroups - creates a private group for each user

Synopsis:

     servers/usergroups [[groups=]everyone]*

Description:

     usergroups is used to give each user a personal /etc/group
     entry.  The program exits silently if there is no "userhome"
     /etc/passwd entry.

     First, the program finds all passwd entries having login
     gids in the specified forbidden group(s).

     Then, for each such entry:
     if the home directory is under "/u", or "/u#",
     and the home directory path ends with the user's userid,
     and no existing group has the same name as the userid,
     a new personal group entry is added to the "/etc/group"
     file, with the group being named after the userid, and, to
     mark it as a personal group, having as a member the userid
     "userhome".

     Then, after the /etc/group file has been updated, the
     "/etc/passwd" file is examined, and all entries with gids
     for personal "/etc/group" entries (i.e. those with with
     userid "userhome" as a member) have their gids reset.

Copyright:

     Copyright (C) 1995, 2003, MFCF, University of Waterloo.

userid_status command

Name:

     userid_status - show the status of all userids on this host

Synopsis:

     servers/userid_status

Description:

     userid_status checks various files, looking for all login
     and mail alias userids on the host, and determines the sta-
     tus of each one.

     Output consists of one line per userid in the form
     "userid:status", sorted alphabetically by userid.

     If more than one status applies to a userid, the first one
     encountered in the following list will be used.

     Zmail
          "/software/zmailer/data/config/lists"

     Sendmail
          "/var/adm/sendmail/aliases"

     DelForward
          "/etc/passwd" - login shell is "/xhbin/Deleting*", but
          the home directory contains a ".forward" file.

     Deleted
          "/etc/passwd" - login shell is "/xhbin/Deleting*".
          i.e. the account is unusable and will be removed at the
          end of the month.

     Expired
          "/software/accounts/data/users" - the account is living
          on borrowed time and unless circumstances change will
          become "Deleted".

     Unused
          "/etc/passwd" - encrypted password is "New-User*".
          i.e. the account has not yet been assigned a password.

     Active
          - /etc/passwd:  the account has been assigned a pass-
          word.

Note:

     This program is normally called only by get_userid_status(8)
     in the accounts-master package.

Copyright:

     Copyright (C) 1995, MFCF, University of Waterloo.

userinfo command (Reasonably Important)

userinfo allowed users to see their own account information/status on the regional client hosts they used. However, it stopped be available for users when the accounts_client package was no longer installed everywhere. That was sort of bad, because it left users no way to check their own status.

Name:

     userinfo - show information about a user

Synopsis:

     userinfo [userid|idnumber] [{+|-}Sponsors]

Description:

     The userinfo command shows various information about a user.
     General information is shown first, followed by information
     specific to the current host.

     The amount and type of information depends both upon how
     privileged the caller is, and upon what information is
     available on the current host.  For instance an anonymous
     user will be shown very little information, while root on
     the accounts_master machine ("math" for MFCF), will be shown
     much more.

     The userid "root", and the groups "operator" and "accounts"
     make extra information available.  Other users may only use
     the command for themselves (no command arguments), or for
     other users (by id number only).

     Unless the -Sponsors option (may be abbreviated as "-spon",
     "-s", etc.)  is given, information about various sponsored
     resources (printers, accounts, ppp access) will be shown
     (available only on the accounts_master machine).  This
     information can be suppressed, since in many cases it can be
     quite verbose (and boring) and make the rest of the output
     difficult to read.

Notes:

     Sometimes the "Name:" field begins with an asterisk.  This
     is based on a flag in the University's uwdir database, indi-
     cating that the user's name (and other personal information)
     must not be made public.  Typically this occurs when a stu-
     dent's registration form requests that home phone numbers
     etc. not be published, though IST may also set the flag for
     other reasons.

     If the caller does not have the "$USER" environment variable
     set, or if that variable is defined as "help", the program
     will interactively ask for a student id number, indicate the
     status of the account, and make suggestions as to where the
     user can go for help.  This behaviour is used for the login
     shell of the "help" userid.

Exit Status:

     The program exits with a status of 1 if no information at
     all can be found about the user on this machine.

Files Used:

     "/software/accounts/config/regional/grace"
     "/software/accounts/data/users"
     "/software/accounts/data/Classes"
     "/software/accounts-userids/data/Students"
     "/software/accounts-userids/data/Userids"
     "/software/accounts/data/Accounts"

Copyright:

     Copyright (C) 1992, 1998, MFCF, University of Waterloo.

-- AdrianPepper - 2019-02-05