SponsorsDataAccountsDocumentationBigPruned < CF

CF Web>Accounts>SponsorsDataAccounts>SponsorsDataAccountsOverview>SponsorsDataAccountsDocumentationBigPruned (2019-02-11, AdrianPepper) (raw view)
EditAttach
---+ Giant Sponsors Database Historical Documentation Page (Pruned)

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

%TOC%
---++ equipment database (PRUNED)
%RED%The equipment database has been moved to the new inventory database.  Any old documentation relating to the equipment database has no relevance.%ENDCOLOR%
<!--
</pre> -->
---++ sponsors database
%RED%An understanding of the old sponsors "database" would be relevant to anyone trying to understand, or create, replacements of it.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts_dev 5 Sponsors
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     sponsors - the accounts-master package's sponsor database


</PRE>
<H4>Synopsis:</H4><PRE>


</PRE>
<H4>Description:</H4><PRE>
     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.


</PRE>
<H4>Structure:</H4><PRE>
     The  data  is  stored  in  a logical hierarchy, each <B>sponsor</B>
     being divided into several  billcodes,  each  <B>billcode</B>  into
     several  classes,  and  each  <B>class</B>  into several <B>resource</B>s.
     Each <I>billcode</I> is assumed to  belong  to  the  most  recently
     encountered  sponsor,  and resets all information associated
     with any previously encountered billcodes.   Each  <I>class</I>  is
     assumed to belong to the most recently encountered billcode,
     and resets all information associated  with  any  previously
     encountered  classes.  Each <I>resource</I> 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.


</PRE>
<H4>Sponsor Section:</H4><PRE>
     This describes the person sponsoring everything that follows
     to the end of the file.

     <B>Sponsor:</B> <I>Name</I> <I>of</I> <I>person</I>

     <B>Department:</B> <I>Sponsor's</I> <I>UW</I> <I>department,</I> <I>if</I> <I>any</I>

     <B>Address:</B> <I>Sponsor's</I> <I>paper</I> <I>mailing</I> <I>address,</I> <I>if</I> <I>any</I>
          Multiple lines may be used if required.

     <B>Email:</B> <I>Sponsor's</I> <I>e-mail</I> <I>address,</I> <I>if</I> <I>any</I>

     <B>Billing:</B> NoCharge
          Sponsor is not charged for sponsored resources.

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

     <B>Statements:</B> NoPaper
          A paper statement is not mailed  to  the  sponsor  each
          month.

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

     <B>Infrastructure:</B> FirstConnection

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


</PRE>
<H4>Billcode SubSection:</H4><PRE>
     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.

     <B>Billcode:</B> <I>UW</I> <I>billcode</I> <I>or</I> <I>equivalent</I>


</PRE>
<H4>Class SubSubSection:</H4><PRE>
     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 <B>list_sponsors(8)</B> will
     begin on a new page for each class.

     <B>Class:</B> <I>Name</I> <I>of</I> <I>class</I>
          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).

     <B>Description:</B> <I>Description</I> <I>of</I> <I>class</I>
          A short description of the purpose of the class.

     <B>Usage:</B> <I>Primary</I> <I>use</I> <I>of</I> <I>the</I> <I>class</I>
          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.).

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

     <B>Instructors:</B> <I>Name</I> <I>of</I> <I>professor,</I> <I>class</I> <I>instructor(s),</I> <I>et</I> <I>al.</I>
          The human(s) responsible for the class.

     <B>Enrollment:</B> <I>Number</I> <I>of</I> <I>members</I>
          The estimated size of the class.

     <B>Load:</B> <I>low,</I> <I>moderate,</I> <I>high,</I> <I>or</I> <I>heavy</I>
          The estimated cpu load for the class.

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

     <B>Fee:</B> <I>Lab</I> <I>fee</I>
          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.

     <B>MembershipStarts:</B> <I>Date</I> <I>to</I> <I>start</I>
          Any  following  membership lists will be ignored before
          this date.

     <B>MembershipEnds:</B> <I>Date</I> <I>to</I> <I>end</I>
          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.

     <B>Members:</B>
          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.


</PRE>
<H4>Resource SubSubSubSection:</H4><PRE>
     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:

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

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

     <B>MailAlias:</B> <I>mail-alias</I>
          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).

     <B>PPP:</B> <I>List</I> <I>of</I> <I>PPP</I> <I>names</I>
          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

     <B>AssignTo:</B> <I>List</I> <I>of</I> <I>userids</I>

     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
     <B>not</B> 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

     <B>IgnoreUserids:</B> <I>List</I> <I>of</I> <I>userids</I>

     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.

     <B>Quota:</B> <I>Restrictions</I> <I>on</I> <I>the</I> <I>amount</I> <I>of</I> <I>the</I> <I>resource</I>
          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.

     <B>SponsorshipStarts:</B> <I>Date</I> <I>sponsorship</I> <I>takes</I> <I>effect</I>
          This is a date before  which  the  sponsorship  of  the
          resource does not apply.

     <B>SponsorshipEnds:</B> <I>Date</I> <I>sponsorship</I> <I>ends</I>
          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.

     <B>Address:</B> <I>IP-Address</I>
          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.

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

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

     <B>Account:</B> <I>Sponsoring</I> <I>account</I>
          This applies only to the printing resource.  If  speci-
          fied,  the  single  <I>account</I>  name  that  will  be  used
          (instead of the <I>class</I> 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.


</PRE>
<H4>Second Attempt At A Descripton:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>

</PRE>
<H4>See Also:</H4><PRE>
     <B>get_all_sponsors(3w)</B>, <B>list_sponsors(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995,2006, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
%BR%
%BR%
---++ list_equipment (PRUNED)
%RED%The equipment database has been moved to the new inventory database.  Any old documentation relating to the equipment database has no relevance.%ENDCOLOR%
<!--
</pre> -->
---++ accounts-master package
%RED%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.%ENDCOLOR%

<!-- <pre>
-H localhost -t accounts-master 7 accounts-master-package
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts-master-package, accounts-master - description of
     the accounts-master package


</PRE>
<H4>Description:</H4><PRE>
     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.


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

     The <B>sponsor_resources(8)</B> 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").


</PRE>
<H4>Sponsored Resources:</H4><PRE>
     The <B>accounts-client(8)</B> 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 <I>spon-</I>
     <B>sor_accounts(8)</B> 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 (<B>expire_accounts(8)</B>) and finally remov-
     ing them and their files (<B>rmallusr(8)</B>).


</PRE>
<H4>Sponsor Reports:</H4><PRE>
     The <B>list_sponsors(8)</B> 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.


</PRE>
<H4>Bugs:</H4><PRE>
     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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>sponsors(5)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1997, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ accounts-client command (VERY IMPORTANT)
%RED% _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.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Accounts-client
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts-client - updates accounts on remote clients


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>accounts-client</B> [[<B>host</B>=]<I>hostname</I>]


</PRE>
<H4>Description:</H4><PRE>
     <B>accounts-client</B> uses the data compiled by the <I>accounts-mas-</I>
     <B>ter(8)</B> program ("/software/accounts-mas-
     ter/data/resources/*/*") and updates all accounts-controlled
     accounts on the specified "<B>host=</B>" 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 "<I>mfcf</I><B>_</B><I>sponsored</I>" machines (the most common
     case), the account resource file is distributed to the
     machine and the <B>sponsor_accounts(8)</B> 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.


</PRE>
<H4>Note:</H4><PRE>
     Unlike <B>accounts-master(8)</B>, this program does not detach
     itself, and so killing it might have some effect on the
     remote updates.


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

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


</PRE>
<H4>See Also:</H4><PRE>
     <B>accounts-master(8)</B>, <B>sponsor_resources(8)</B>, <B>do_polaris(8)</B>,
     <B>sponsor_accounts(8)</B>, <I>mfcf-course-accounts</I>(i).


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996, 1997, 2009, MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ accounts-master command (Reasonably Important)
%RED% _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. %ENDCOLOR%

%RED% Apparently missing here is a man page for _make_all_accounts_ which does the actual work %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Accounts-master
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts-master - gathers current information for maintain-
     ing accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>accounts-master</B> [{+|-}<B>Verbose</B>]


</PRE>
<H4>Description:</H4><PRE>
     <B>accounts-master</B> 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, <B>accounts-client(8)</B>, 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 "<B>+Verbose</B>", 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 "<B>-Verbose</B>" 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 <I>accounts-</I>
     <I>master</I> program without affecting the actual update.


</PRE>
<H4>Bugs:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts-master/data/sponsors/
     /software/accounts-master/data/resources/
     /software/accounts/logs/accounts-master


</PRE>
<H4>See Also:</H4><PRE>
     <B>accounts-client(8)</B>, <B>sponsor_resources(8)</B>, <I>mfcf-course-</I>
     <I>accounts</I>(i).


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1994,1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ check_equipment command (PRUNED)
%RED%The equipment database has been moved to the new inventory database.  Any old documentation relating to the equipment database has no relevance.%ENDCOLOR%
<!--
</pre> -->
---++ check_network command (PRUNED)
%RED%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.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 check_network
-->
<!--
</pre> -->
---++ get_printer_quotas command
<!-- <pre>
-H localhost -t accounts-master 8 Get_printer_quotas
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     get_printer_quotas - merge requests for accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>get_printer_quotas</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>get_printer_quotas</B> 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 - &lt; lpquotas.update.ps_mfcf
          math% lpquota_update_sucks -p [ ... ] - &lt; 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.

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

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


</PRE>
<H4>Files:</H4><PRE>
     /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.&lt;printer&gt;


</PRE>
<H4>See Also:</H4><PRE>
     <B>lpquota_update_sucks(8)</B>,


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ get_student_registry command (OBSOLETE)
%RED% This command is probably a predecessor of _download_accounts_data_. (Used by _accounts_master_ ). %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Get_student_registry
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     get_student_registry - fetch the current student registry
     from Data Processing


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>get_student_registry</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>get_student_registry</B> 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)


</PRE>
<H4>Files</H4><PRE>
     /software/accounts-master/data/temp/student_registry


</PRE>
<H4>See Also:</H4><PRE>
     <B>register_student_programs(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ get_userid_status command
<!-- <pre>
-H localhost -t accounts-master 8 Get_userid_status
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     get_userid_status - gather the userid statuses in our admin-
     istration


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>get_userid_status</B> <I>host</I>*


</PRE>
<H4>Example:</H4><PRE>
     set hosts=`include_files config/hosts_mail | decomment`
     get_userid_status `cat $hosts`  &gt;addresses


</PRE>
<H4>Description:</H4><PRE>
     <B>get_userid_status</B> runs <B>userid_status(8)</B> on each <B>host</B> 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 "<I>id</I>" is the student,
     employee, or other id number associated with the userid, and
     "<I>status</I>" is one of: "Active", "Zmail", "Sendmail",
     "Expired", "Unused", "DelForward", "Deleted", or "Unknown",
     as described in <B>mail_registry(8)</B>.


</PRE>
<H4>Note:</H4><PRE>
     This program is normally run only by the <B>register_mail(8)</B>
     program to produce input for the <B>mail_registry(8)</B> program.


</PRE>
<H4>See Also:</H4><PRE>
     <B>userid_status(8)</B>, <B>mail_registry(8)</B>, <B>register_mail(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ inuse command
%RED% 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. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Inuse
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     inuse - query IST's inuse userid database


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>inuse</B> [<I>grep</I> <I>arguments</I>]


</PRE>
<H4>Description:</H4><PRE>
     <B>inuse</B> 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 '\\\&lt;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).


</PRE>
<H4>Notes:</H4><PRE>
     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.


</PRE>
<H4>Commands Used:</H4><PRE>
     /software/gnu/bin/grep -E


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1998, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ list_classes command
<!-- <pre>
-H localhost -t accounts-master 8 List_classes
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     list_classes - list MFCF-resource classes


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


</PRE>
<H4>Options:</H4><PRE>
     [<B>Sponsors</B>=/software/accounts-master/data/sponsors/REGISTRAR]
          Directory (or file) containing class sponsorship infor-
          mation.

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

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

     [<B>+Colons</B>]
          Display output as colon-separated fields.

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


</PRE>
<H4>Description:</H4><PRE>
     <B>list_classes</B> 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.


</PRE>
<H4>Examples:</H4><PRE>
          list_classes class enrollment load instructor comment \
               &gt;/software/mfcf-specific/man/mani/mfcf-classes.i
          list_classes cents printer class kbytes host instructor +reg \
               &gt;/software/mfcf-specific/mani/mfcf-class-resources.i


</PRE>
<H4>See Also:</H4><PRE>
     <I>sponsors</I>5


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1993,1997,2001, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ list_sponsors command
<!-- <pre>
-H localhost -t accounts-master 8 List_sponsors
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     list_sponsors - list resource sponsors


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


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


</PRE>
<H4>Options:</H4><PRE>
     [[<B>sponsorpath</B>=]/software/accounts-master/data/sponsors]*
          Files (or directories to be recursively descended) con-
          taining the sponsor data.

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

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

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

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

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


</PRE>
<H4>Description:</H4><PRE>
     <B>list_sponsors</B> 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 "<I>ListNames=users</I>" option to minimize the
     time it takes and the size of the standard output produced.


</PRE>
<H4>Standard Output:</H4><PRE>
     For the "<I>ListNames=users</I>" 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.


</PRE>
<H4>Error Output:</H4><PRE>
     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 <I>must</I> 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
          "<I>HaveExpired=</I>" 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.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/sponsors/*/*


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1993, 1994, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mail_deletion command
<!-- <pre>
-H localhost -t accounts-master 8 Mail_deletion
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mail_deletion - gather invalid uwdir mail addresses


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>mail_deletion</B> &lt;<I>host-file</I> <B>Outputdirectory=</B><I>path</I>
          <B>Registered=</B><I>registered-file</I> <B>Status=</B><I>status-file</I>


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

     Registered addresses with hosts that are not named in the
     <B>host-file</B> are ignored.

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


</PRE>
<H4>Note:</H4><PRE>
     This program is normally run only by the <B>register_mail(8)</B>
     program.


</PRE>
<H4>See Also:</H4><PRE>
     <B>get_userid_status(8)</B>, <B>userid_status(8)</B>, <B>uwdir-submit(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995,2010 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mail_registry command
<!-- <pre>
-H localhost -t accounts-master 8 Mail_registry
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mail_registry - gather mail addresses suitable for uwdir


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>mail_registry</B> [Domain=<I>uwaterloo.ca</I>]


</PRE>
<H4>Description:</H4><PRE>
     <B>mail_registry</B> reads a list of mail addresses as produced by
     the <B>get_userid_status(8)</B> 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:

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

     <B>Zmail</B>
          "/software/zmailer/data/config/lists"

     <B>Sendmail</B>
          "/var/adm/sendmail/aliases"

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

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

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

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

     <B>Unknown</B>
          - 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 <B>userid_status(8)</B>.


</PRE>
<H4>Note:</H4><PRE>
     This program is normally run only by the <B>register_mail(8)</B>
     program.


</PRE>
<H4>See Also:</H4><PRE>
     <B>get_userid_status(8)</B>, <B>userid_status(8)</B>, <B>uwdir-submit(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995,2010, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ make_remote_accounts command (IMPORTANT)
<!-- <pre>
-H localhost -t accounts-master 8 Make_remote_accounts
-->
%RED% Details in this page, however, are severely out-of-date. %ENDCOLOR%
%RED% Details in this page, however, are severely out-of-date. %ENDCOLOR%
%RED% 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). %ENDCOLOR%
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     make_remote_accounts - makes remote accounts.


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>make_remote_accounts</B> [-h <B>hostname</B>]


</PRE>
<H4>Description:</H4><PRE>
     This should not be called by anyone or anything other than
     by the <B>accounts-client(8)</B> program.

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


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts-master/data/control/{Classes,Special},
     /software/accounts-master/data/work/*.


</PRE>
<H4>Bugs:</H4><PRE>
     Can only handle userids that have student id numbers.


</PRE>
<H4>See Also:</H4><PRE>
     <I>accounts-master(8)</I>, <I>accounts-client(8)</I>, <I>make-all-</I>
     <I>accounts(8)</I>, <I>mfcf-course-accounts(i)</I>, <I>mkstuds(8)</I>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1994, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ merge_account_requests command (OBSOLETE)
%RED% This has been superseded by something.  %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Merge_account_requests
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     merge_account_requests - merge requests for accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     sort requests  <B>merge_account_requests</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>merge_account_requests</B> 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)


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/temp/student_registry_mfcf


</PRE>
<H4>See Also:</H4><PRE>
     <B>register_userids(8)</B>, <B>get_special(8)</B>, <I>get</I><B>_</B><I>student</I><B>_</B><I>reg-</I>
     <B>istry(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ net_update_sql command
<!-- <pre>
-H localhost -t accounts-master 8 Net_update_sql
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     net_update_sql - produce SQL commands to update inventory
     database SNMP info


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>net_update_sql</B> [<B>Input</B>=]/software/accounts-mas-
     ter/data/networks/NetInfo


</PRE>
<H4>Description:</H4><PRE>
     <B>net_update_sql</B> examines the ping and SNMP data compiled by
     network scanning and produces SQL commands to update the
     inventory database.


</PRE>
<H4>See Also:</H4><PRE>
     <B>scan_network(8)</B>, <B>check_network(8)</B>, <B>update_network(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2008 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ register_mail command
<!-- <pre>
-H localhost -t accounts-master 8 Register_mail
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     register_mail - send preferred mail addresses to uwdir


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>register_mail</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>register_mail</B> 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 <B>quwdir(1)</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>get_userid_status(8)</B>, <B>userid_status(8)</B>, <B>mail_deletion(8)</B>,
     <B>mail_registry(8)</B>, <B>quwdir(1)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995,2008 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ register_student_programs command (OBSOLETE)
%RED% This has been superseded by something.  %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Register_student_programs
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     register_student_programs - merge requests for accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>register_student_programs</B> <B>&lt;input</B> <B>&gt;output</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>register_student_programs</B> fetches requests for accounts from
     standard input (which are in the computing services format
     (see <B>get_student_registry(8)</B>)) 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.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/temp/student_registry,
     /software/accounts-master/data/temp/student_registry_mfcf.


</PRE>
<H4>See Also:</H4><PRE>
     <B>register_userids(8)</B>, <B>get_special(8)</B>, <I>get</I><B>_</B><I>student</I><B>_</B><I>reg-</I>
     <B>istry(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ scan_network command (PRUNED)
%RED%The equipment database has been moved to the new inventory database.  Any old documentation relating to the equipment database has no relevance.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Scan_network
-->
<!--
</pre> -->
---++ select_classes command
<!-- <pre>
-H localhost -t accounts-master 8 Select_classes
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     select_classes - select classes of users for account cre-
     ation


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>select_classes</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>select_classes</B> reads account requests from its standard
     input and selects those that match entries in the Classes
     file.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/host/Classes


</PRE>
<H4>See Also:</H4><PRE>
     <B>make_account_requests(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ sponsor_resources command (VERY IMPORTANT)
%RED% _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.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts-master 8 Sponsor_resources
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     sponsor_resources - generate resource data from sponsors
     data

     <B>'Warning:</B> <B>This</B> <B>is</B> <B>still</B> <B>under</B> <B>development."</B>


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>sponsor_resources</B> <B>Severity</B>=Warnings|Notes|Errors
     [<B>sponsors</B>=]/software/accounts-master/data/sponsors
     <B>Configdirectory</B>=/software/accounts-master/data/sponsors/.Config
     <B>Resources</B>=/software/accounts-master/data/resources
     <B>Expired</B>=90
     <B>Today</B>=today


</PRE>
<H4>Options:</H4><PRE>
     [<B>sponsors</B>=]/software/accounts-master/data/sponsors
          Directories or files containing the sponsors database.

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

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

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

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

     <B>Today</B>=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.


</PRE>
<H4>Description:</H4><PRE>
     <B>sponsor_resources</B> 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.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/sponsors/*/*
     /software/accounts-master/data/resources/{account,printer,ppp}/*


</PRE>
<H4>See Also:</H4><PRE>
     <B>accounts-master(8)</B> - calls <I>sponsor</I><B>_</B><I>resources</I> and even more
     <B>accounts-client(8)</B> - update remote accounts
     <B>list_sponsors(8)</B> - explanation of error messages


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996, 1997, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ update_network command (PRUNED)
%RED%The equipment database has been moved to the new inventory database.  Any old documentation relating to the equipment database has no relevance.%ENDCOLOR%
<!--
</pre> -->
---++ update_web_pages command
<!-- <pre>
-H localhost -t accounts-master 8 Update_web_pages
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     update_web_pages - update mfcf web pages with mfcf.math data


</PRE>
<H4>Synopsis:</H4><PRE>
     update_web_pages


</PRE>
<H4>Options:</H4><PRE>
     <B>none</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>update_web_pages</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>webify_owner_groups(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2001, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ webify_owner_groups command
<!-- <pre>
-H localhost -t accounts-master 8 webify_owner_groups
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     webify_owner_groups - produce supported host web pages from
     Owners data


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/webify_owner_groups
     [<B>outputDirectory</B>=/software/accounts-master/data/work/web-
     ify_owner_groups]
     [<B>GroupDescriptions</B>=/software/accounts-master/data/own-
     ers/.Config/groups]
     [[<B>ownerpath</B>=]/software/accounts-master/data/owners]


</PRE>
<H4>Options:</H4><PRE>
     <B>outputDirectory</B>=
          Directory where the html files are to be dumped

     <B>GroupDescriptions</B>=
          File containing host group descriptions.

     [<B>ownerpath</B>=]
          File or directory containing owner information.


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

     All output is put into the specified directory (<B>outputDirec-</B>
     <B>tory</B>=).  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.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-master/data/work/webify_owner_groups/*
     /software/accounts-master/data/owners/.Config/groups
     /software/accounts-master/data/owners/*
     <B>check_owners(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2001, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
%BR%
---++ diskquota command (OBSOLETE)
%RED% Eventually things changed so the vendor _quota_ command would work. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 1 diskquota
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     diskquota - show disk quota


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>diskquota</B> [-<B>Remote</B>] [<B>userid</B>|<B>uid</B>]*


</PRE>
<H4>Description:</H4><PRE>
     The <B>diskquota</B> 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 -<B>Remote</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>quota(1)</B>


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/config/regional/fashosts
     /software/accounts/config/regional/rquotahosts


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1993,2003,2005,2008 MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ groups command (BEWARE)
%RED% Some people did not like the sometime tendency of _xhier_ to provide locally enhanced versions of standard commands. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 1 groups
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>NAME</H4><PRE>
     groups - show group memberships


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>groups</B> <B>[-s&lt;sep&gt;]</B> <B>[-p]</B> <B>[user]</B>
     <B>groups</B> <B>[-s&lt;sep&gt;]</B> <B>[-p]</B> <B>-{g|G}</B> <B>group_name</B>
     <B>groups</B> <B>[-s&lt;sep&gt;]</B> <B>[-p]</B> <B>-{g|G}</B> <B>group_id</B>


</PRE>
<H4>DESCRIPTION</H4><PRE>
     The <I>groups</I> command shows the groups to which you or the
     optionally specified user belong.

     If the <B>-p</B> 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 <B>-g</B> 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 <B>-G</B> 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 <B>-s</B> 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&amp;R 2nd ed. sec-
     tion 2.3.

     Each user belongs to a group specified in the password file
     <I>/etc/passwd</I> and possibly to other groups as specified in the
     file <I>/etc/group</I>.  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.


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>setgroups(2)</B>


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd, /etc/group


</PRE>
<H4>BUGS</H4><PRE>
     More groups should be allowed.
     groups in.


</PRE>
<H4>UW DIFFERENCES</H4><PRE>
     The <B>-g</B>, <B>-G</B>, <B>-p</B>, and <B>-s</B> options are UW enhancements.

</PRE>
<!--
</pre> -->
---++ init_home command (Somewhat Important)
%RED% 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.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 1 init_home
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     init_home - reinitialize your home directory


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>init_home</B> [userid]*


</PRE>
<H4>Description:</H4><PRE>
     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.


</PRE>
<H4>Configuration:</H4><PRE>
     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.  <I>init</I><B>_</B><I>home</I> will
     initialize the ".forward" and ".rhosts" files for these
     accounts (but will not replace existing instances thereof).


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/config/*/init_home
     /software/accounts/config/admin/common_users


</PRE>
<H4>See Also:</H4><PRE>
     <B>.cshrc(5)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1990, 1997, 2005, 2006, MFCF, University of
     Waterloo.
</PRE>
<!--
</pre> -->
---++ lastlog command (PRUNED)
<!-- <pre>
-H localhost -t accounts 1 lastlog
-->
<!--
</pre> -->
---++ laston command (PRUNED)
<!-- <pre>
-H localhost -t accounts 1 laston
-->
<!--
</pre> -->
---++ password command
%RED% This was suspiciously close to a local cover for standard vendor commands.  %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 1 password
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     password - change a user's password


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>password</B>  <I>Userid</I><B>_</B><I>Or</I><B>_</B><I>Idnumber</I>
     <B>password</B>  <I>Userid</I><B>_</B><I>Or</I><B>_</B><I>IdNumber</I>  <B>+Randompassword</B>
     <B>password</B>  <I>Userid</I><B>_</B><I>Or</I><B>_</B><I>IdNumber</I>  <B>Encryptedpassword=</B><I>string</I>


</PRE>
<H4>Description:</H4><PRE>
     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
     "<B>id</B> <B>number</B>", 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 <B>users(5)</B>).

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

     The "<B>Encryptedpassword=string</B>" 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 "<I>operator</I>", "<I>opcons</I>", or "<I>staff</I>" may change
     passwords only on accounts that have an illegal encrypted
     value, providing the first character is not a "*".  Someone
     in group "<I>accounts</I>" 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".


</PRE>
<H4>See Also:</H4><PRE>
     <B>passwd(1)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1989, 1998, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ courses file (INTERESTING HISTORY)
%RED% This probably predates the current _sponsors data_ set of files. The current _sponsors data_ set of files was designed by admininstrative assistant Christie Gillin. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 5 courses
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>Name:</H4><PRE>
     Courses - accounts database of student courses


</PRE>
<H4>Synopsis:</H4><PRE>
     /software/regtape/data/Courses
     /software/accounts/data/host/Courses


</PRE>
<H4>Description:</H4><PRE>
     The file <B>/software/regtape/data/Courses</B> 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
     <I>/software/accounts/data/host/Courses</I>.

     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.


</PRE>
<H4>Example:</H4><PRE>
          #
          #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


</PRE>
<H4>Files:</H4><PRE>
     /software/regtape/data/Courses
     /software/accounts/data/host/Courses


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (c) 1990, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ fashosts file
<!-- <pre>
-H localhost -t accounts 5 fashosts
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     fashosts - declare remote fileserver information


</PRE>
<H4>Synopsis:</H4><PRE>
     /software/accounts/config/regional/fashosts


</PRE>
<H4>Description:</H4><PRE>
     The file <I>/software/accounts/config/regional/fashosts</I> 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.


</PRE>
<H4>Examples:</H4><PRE>
     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


</PRE>
<H4>Bugs:</H4><PRE>
     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.


</PRE>
<H4>Development:</H4><PRE>
     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)


</PRE>
<H4>See Also:</H4><PRE>
     <B>mkquota(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2008, MFCF,CSCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ users file (VERY IMPORTANT)
%RED% _/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_ . %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 5 users
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     users - user account related information


</PRE>
<H4>Synopsis:</H4><PRE>
     /software/accounts/data/users


</PRE>
<H4>Description:</H4><PRE>
     The file <I>/software/accounts/data/users</I> contains information
     about user accounts, complementing the <I>/etc/passwd</I> 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".

     <B>name</B> contains the full untruncated userid of the user.

     <B>quota</B>
          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
          <I>accounts</I> or <I>accounts</I><B>_</B><I>client</I> packages.]

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

     <B>type</B> [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 <I>/software/setpw/config/arch/vendor.passwd</I>
          and <I>/software/*/export/passwd</I>.  If the first eight
          characters of the field are "sponsor-", the account is
          controlled by the <B>sponsor_accounts(8)</B> program in the
          <I>accounts</I><B>_</B><I>client</I> package.

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

          This <I>sponsor</I> 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 <B>mkmerge(8)</B> program in the <I>accounts</I>
          package, via calls from the <B>make_remote_accounts(8)</B>
          program in the <I>accounts-master</I> package.  If the field
          contains anything else, the account is not affected by
          either of these two accounts maintenance mechanisms.

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

     <B>info</B> For <I>student</I> accounts, this contains the classes in
          which the user is enrolled, in the form: "Name-Number-
          Term-dd/mm/yy".  For <I>sponsored</I> 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 <I>xhier</I> accounts,
          this field contains the names of the sponsoring xhier
          packages.


</PRE>
<H4>Files:</H4><PRE>
     /software/acccounts/data/users


</PRE>
<H4>See Also:</H4><PRE>

</PRE>
<H4>Bugs:</H4><PRE>

</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991,1996,2005, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ accounts package configuration
%RED% This must contains errors because of obsolete details. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 7 accounts-config
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts-config - configuring the accounts package


</PRE>
<H4>Description:</H4><PRE>
     The <I>accounts</I> package can be configured to suit various
     administrations and individual hosts.  Some of those config-
     urations are described below.


</PRE>
<H4>Mail (old method):</H4><PRE>
     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
     "<B>admin_accounts</B>", which is controled by the package's admin-
     istration file "<B>export/aliases</B>".  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 <B>/software/local_</B>[hostname]<B>/export/aliases</B> 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.


</PRE>
<H4>Mail (new method):</H4><PRE>
     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 "<B>export/aliases</B>"
     file or by centralized automated alias administration) sim-
     ply do something such as setting
     "accounts-&gt;admin_accounts@adminhost" everywhere, and then
     have an alias for "admin_accounts" on the central admin
     host.


</PRE>
<H4>Configuring first-time user's information:</H4><PRE>
     When an account is created, the standard ".cshrc", ".pro-
     file", and ".xsession" files typically contain an invocation
     of the "<B>first_login</B>" 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 "<B>con-</B>
     <B>fig/share/first_time</B>" file.

     An administration can override this file by editing, on the
     administration host, the file "<B>config/admin/first_time</B>",
     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 "<B>config/local/first_time</B>", 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.


</PRE>
<H4>Account expiry:</H4><PRE>
     (Applies to the "accounts_client" package only.)

     The regional file "<B>config/regional/grace</B>" 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.


</PRE>
<H4>Basic disk quota:</H4><PRE>
     (Applies to the "accounts_client" package only.)

     The regional file "<B>config/regional/quota_basic</B>" may contain
     a line giving the number of kilobytes of basic disk quota
     (e.g. for <I>.cshrc</I> 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.


</PRE>
<H4>Configuring orphan:</H4><PRE>
     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 <B>orphan(8)</B> for other configuration details.


</PRE>
<H4>Configuring accounts_check:</H4><PRE>
     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.


</PRE>
<H4>Configuring home directory creation:</H4><PRE>
     When the <B>acount_update(8)</B> 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.


</PRE>
<H4>Configuring home directory content:</H4><PRE>
     New home directories are initialized using the templates
     defined by "<B>config/*/init_home</B>".  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 "<I>/soft-</I>
     <I>ware/accounts/data/host/standard</I>" 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.


</PRE>
<H4>Configuring initial .forward and .rhosts:</H4><PRE>
     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 "<B>config/admin/common_users</B>" 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 <B>init_home(1)</B> program.


</PRE>
<H4>Configuring initial login shell:</H4><PRE>
     New accounts are created using the shell determined by "<B>xh-</B>
     <B>options</B>  <B>-p</B> <B>accounts</B>  <B>-c</B> <B>initial</B>  <B>Shell</B>", i.e. by the
     "<I>Shell=</I>" option in the files "<B>config/*/initial</B>".


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


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

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

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


</PRE>
<H4>Configuring group control</H4><PRE>
     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
     <B>edit_group(8)</B> for specific details.


</PRE>
<H4>Configuring id conformance:</H4><PRE>
     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 <B>idregistry(8)</B>
     for specific details.


</PRE>
<H4>Bugs:</H4><PRE>
     The local version of the first_time file is probably a lot
     less useful than a regional version.


</PRE>
<H4>Files:</H4><PRE>
     /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


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992, 2005, MFCF, University of Waterloo

</PRE>
<!--
</pre> -->
---++ accounts_backup command (WAS VERY USEFUL)
<!-- <pre>
-H localhost -t accounts 8 accounts_backup
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts_backup - save copies of some important files.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>accounts_backup</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>accounts_backup</B> makes copies of some important files, such
     as /etc/passwd, /etc/group, .../host/users, and secu-
     rity/data/super_users.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1988, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ accounts_check command
<!-- <pre>
-H localhost -t accounts 8 accounts_check
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts_check - check inconsistencies in accounts files


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>accounts_check</B> [-<I>doRegionalClient</I>] [-<I>checkCoursePasswords</I>]
     [+<I>checkUsersFile</I>] [+<I>checkRootPasswords</I>] [+<I>checkAllHomes</I>]

     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.


</PRE>
<H4>Description:</H4><PRE>
     <B>accounts_check</B> examines the files "<I>/etc/passwd</I>",
     "<I>/etc/group</I>", "<I>/software/accounts/data/host/users</I>", and
     "<I>/software/security/data/super</I><B>_</B><I>users</I>", "<I>/software/secu-</I>
     <I>rity/data/securid</I><B>_</B><I>users</I>", and reports any inconsistencies
     between them.

     Unless the "<B>+doRegionalClient</B>" 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 "<B>+checkAllHomes</B>" 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 "<I>other</I>" and "<I>users</I>"
          both exist, they should have the same gid.  Similarly
          for "<I>root</I>" and "<I>wheel</I>".

     -    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 "<B>-checkCoursePasswords</B>"
          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 "<B>+checkUsersFile</B>"
          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 "<B>+checkRootPasswords</B>"
          option.

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


</PRE>
<H4>Configuration:</H4><PRE>
     The files "<I>/software/accounts/config/&lt;type&gt;/accounts</I><B>_</B><I>check</I>",
     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,
     "<B>RootPasswordHosts=host1,host2,...</B>", 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.


</PRE>
<H4>See Also:</H4><PRE>
     <I>syntax</I>(i)


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1988, 1996 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ accounts_check_region command
<!-- <pre>
-H localhost -t accounts 8 accounts_check_region
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     accounts_check_region - record and check xhier regions


</PRE>
<H4>OBSOLETE:</H4><PRE>
     <B>These</B> <B>hostin</B> <B>groups</B> <B>have</B> <B>now</B> <B>moved</B> <B>to</B> <B>the</B> <B>xhier</B> <B>package</B>
     <B>where</B> <B>they</B> <B>should</B> <B>have</B> <B>been</B> <B>in</B> <B>the</B> <B>first</B> <B>place.</B>  See
     RT#12751.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>accounts_check_region</B> {<B>Client</B>|<B>Server</B>}


</PRE>
<H4>Description:</H4><PRE>
     <B>accounts_check_region</B> is run by the Install script of the
     accounts package, its argument indicating whether <I>xh-is-</I>
     <B>regional-server(8)</B> thinks the host is an xhier regional
     server or client.

     On an xhier regional <I>server</I> 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 <I>client</I> 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.


</PRE>
<H4>Files Used:</H4><PRE>
     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/<I>&lt;hostname&gt;</I>
     /software/accounts/data/regional-clients/<I>&lt;hostname&gt;*</I>

     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.


</PRE>
<H4>Bugs:</H4><PRE>
     The command should be called <B>xh-check-region(8)</B>, 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.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ check_rhosts command
<!-- <pre>
-H localhost -t accounts 8 check_rhosts
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     check_rhosts - report dubious .rhosts entries


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>check_rhosts</B> [<B>userid=</B>]<I>userid</I> * [<B>+Verbose</B>]


</PRE>
<H4>Description:</H4><PRE>
     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.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ currentdisk command
<!-- <pre>
-H localhost -t accounts 8 currentdisk
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     currentdisk - display usage for local file systems with
     quota


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>currentdisk</B> [+<B>FileSystems</B>] [+<B>Headings</B>] [+<B>Percent</B>]


</PRE>
<H4>Description:</H4><PRE>
     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.

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


</PRE>
<H4>Examples:</H4><PRE>
     # 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:


</PRE>
<H4>Configuration:</H4><PRE>
     There are two regional configuration files:

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

     /software/accounts/config/regional/<B>accounting_nfs</B>
          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 <B>not</B> the name of the host where the files
     are mounted from.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1999,2000,2007 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ disable_user command
%RED% Will something like this be easily available to, e.g. MFCF consultants and CSCF help desk? %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 disable_user
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     disable_user, enable_user - disable or enable an exceptional
     user


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>disable_user</B> [userid=]<I>userid</I> [Reason=<I>'The</I> <I>reason.'</I>]
                  [SecretReason=<I>'The</I> <I>real</I> <I>reason.'</I>]
                  [cannedMessage=<I>various-message-names</I>]
     <B>enable_user</B> [userid=]<I>userid</I> [Reason=<I>'The</I> <I>reason.'</I>]


</PRE>
<H4>Description:</H4><PRE>
     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.

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

     Exactly one of <B>Reason</B>= or <B>cannedMessage</B>= 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 <B>SecretReason</B>= 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.


</PRE>
<H4>Notes:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/logs/disable
     /software/accounts/config/*/disabled_messages/*
     /software/accounts/data/disabled/secret_why/userid
     /software/accounts/data/disabled/why/userid


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ disabled_shell command
%RED% Part of the account disabling feature. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 disabled_shell
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     disabled_shell - politely reject a user


</PRE>
<H4>Synopsis:</H4><PRE>
     /xhbin/<B>disabled_shell</B>


</PRE>
<H4>Description:</H4><PRE>
     The <B>disabled_shell</B> 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.


</PRE>
<H4>Files Used:</H4><PRE>
     "/software/accounts/data/disabled/why/&lt;userid&gt;"


</PRE>
<H4>See Also:</H4><PRE>
     <B>disable_user(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, 2000, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ edit_finger command (Obsolete)
%RED% Privacy overrides publication in the current world order. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 edit_finger
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>edit_rhosts</B> userid
     <B>edit_forward</B> userid
     <B>edit_shell</B> userid
     <B>edit_finger</B> userid


</PRE>
<H4>Description:</H4><PRE>
     <I>edit</I><B>_</B><I>rhosts</I> etc. allow someone in group <I>accounts</I> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>setpasswd(8)</B> - edit or change some fields in passwd file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ edit_forward command (Unimportant)
<!-- <pre>
-H localhost -t accounts 8 edit_forward
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>edit_rhosts</B> userid
     <B>edit_forward</B> userid
     <B>edit_shell</B> userid
     <B>edit_finger</B> userid


</PRE>
<H4>Description:</H4><PRE>
     <I>edit</I><B>_</B><I>rhosts</I> etc. allow someone in group <I>accounts</I> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>setpasswd(8)</B> - edit or change some fields in passwd file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ edit_group command
%RED% Provided limited privilege for, e.g. course co-ordinators %ENDCOLOR%
%RED% At some point it was decided there was no need to use Posix groups for anything. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 edit_group
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     edit_group - set or change /etc/group entries


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>edit_group</B> [<B>group=</B>]groupname [+<B>Create</B>] [+<B>Differences</B>]
     [<B>Add</B>=userid[,...]]*  [<B>Delete</B>=userid[,...]]*  [<B>Comment</B>='To
     remember why.']


</PRE>
<H4>Description:</H4><PRE>
     <B>edit_group</B> 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.

     [<B>group=</B>]<I>groupname</I>
          is the name of the group to be edited.

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

     <B>Add</B>=<I>userid,...</I>
          specifies userid(s) to be added to the group.

     <B>Delete</B>=<I>userid,...</I>
          specifies userid(s) to be deleted from the group.

     <B>Comment</B>=<I>Why.</I>
          gives an optional comment to be entered into the log
          file.

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


</PRE>
<H4>Configuration:</H4><PRE>
     The file "/software/accounts/config/regional/edit_group" may
     contain the following options:

     <B>MaxGroups</B>=<I>number</I>
          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.

     <B>LocalControl</B>=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.

     <B>SubGroups</B>=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.


</PRE>
<H4>Bugs:</H4><PRE>
     Doesn't yet allow the renaming of groups.

     Doesn't yet allow the deletion of groups.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/logs/edit_group
     /software/accounts/config/regional/edit_group
     /etc/group
     /etc/group.lock


</PRE>
<H4>See Also:</H4><PRE>
     <B>setpasswd(8)</B> - edit or change some fields in passwd file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995,2003, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ edit_rhosts command (Unimportant)
<!-- <pre>
-H localhost -t accounts 8 edit_rhosts
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>edit_rhosts</B> userid
     <B>edit_forward</B> userid
     <B>edit_shell</B> userid
     <B>edit_finger</B> userid


</PRE>
<H4>Description:</H4><PRE>
     <I>edit</I><B>_</B><I>rhosts</I> etc. allow someone in group <I>accounts</I> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>setpasswd(8)</B> - edit or change some fields in passwd file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ edit_shell command (Consider)
<!-- <pre>
-H localhost -t accounts 8 edit_shell
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     edit_rhosts, edit_forward, edit_shell, edit_finger - set or
     change .rhosts, .forward, shell, or finger info for a non-
     password userid.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>edit_rhosts</B> userid
     <B>edit_forward</B> userid
     <B>edit_shell</B> userid
     <B>edit_finger</B> userid


</PRE>
<H4>Description:</H4><PRE>
     <I>edit</I><B>_</B><I>rhosts</I> etc. allow someone in group <I>accounts</I> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>setpasswd(8)</B> - edit or change some fields in passwd file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1990, 1996, 1998, MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ enable_user command
<!-- <pre>
-H localhost -t accounts 8 enable_user
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     disable_user, enable_user - disable or enable an exceptional
     user


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>disable_user</B> [userid=]<I>userid</I> [Reason=<I>'The</I> <I>reason.'</I>]
                  [SecretReason=<I>'The</I> <I>real</I> <I>reason.'</I>]
                  [cannedMessage=<I>various-message-names</I>]
     <B>enable_user</B> [userid=]<I>userid</I> [Reason=<I>'The</I> <I>reason.'</I>]


</PRE>
<H4>Description:</H4><PRE>
     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.

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

     Exactly one of <B>Reason</B>= or <B>cannedMessage</B>= 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 <B>SecretReason</B>= 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.


</PRE>
<H4>Notes:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/logs/disable
     /software/accounts/config/*/disabled_messages/*
     /software/accounts/data/disabled/secret_why/userid
     /software/accounts/data/disabled/why/userid


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ findall command
<!-- <pre>
-H localhost -t accounts 8 findall
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>NAME</H4><PRE>
     findall - find files owned by any of a group of users


</PRE>
<H4>SYNOPSIS</H4><PRE>
     server <B>findall</B> [ <B>f=fileout</B> ] [ <B>d=dirout</B> ] [ <B>u=userin</B> ]
     directory users ...


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

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

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

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


</PRE>
<H4>EXAMPLES</H4><PRE>
     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.


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>find(1)</B>

</PRE>
<!--
</pre> -->
---++ fsuserclean command
<!-- <pre>
-H localhost -t accounts 8 fsuserclean
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     fsuserclean - find and process files owned by deleted users


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>fsuserclean</B> [<B>Orphan</B>='orphan'] [<B>Remove</B>=/u[,...]]
     [<B>Start</B>=/] Uids<B>=filename</B>


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

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


</PRE>
<H4>Options:</H4><PRE>
     [<B>Orphan</B>=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.

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

     [<B>Start</B>=/]
          Filesystem root.

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


</PRE>
<H4>See Also:</H4><PRE>
     <B>rmallusr(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2002, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ id_renumber command
<!-- <pre>
-H localhost -t accounts 8 id_renumber
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     id_renumber - walk directory tree changing file ownership


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>id_renumber</B> [<B>+Quiet</B>] [<B>+Test</B>] [<B>+NFS</B>] [<B>Map=</B><I>map</I>]...  [<B>+Stdin</B>]
     [<I>directory</I>]...


</PRE>
<H4>Where:</H4><PRE>
     <B>+Quiet</B>
          produces no output if nothing is renumbered

     <B>+Test</B>
          shows changes which would be made without making them

     <B>+NFS</B> allows NFS filesystems to be traversed.

     <B>Map=</B><I>map</I>
          specifies an id mapping to perform.

     <B>+Stdin</B>
          causes id mappings to be read from standard input.

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


</PRE>
<H4>Description:</H4><PRE>
     <B>Id_renumber</B> walks directory trees performing uid or gid map-
     ping on files and directories.

     The <B>Test</B> 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 <B>Quiet</B> option is given, those headers will
     only be generated if other output occurs.

     <I>id</I><B>_</B><I>renumber</I> does not follow symlinks or NFS mounted file
     systems.  NFS mounted filesystems can be checked by using
     the <B>+NFS</B> option, but in that case non-NFS filesystems will
     be ignored.

     While walking a tree, it will skip (stop walking) any paths
     in the <B>decomment(1)</B>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).


</PRE>
<H4>Mappings:</H4><PRE>
     Mappings must be of the form:

          <B>uid:</B><I>oldnumber</I><B>:</B><I>newnumber</I>
     or
          <B>gid:</B><I>oldnumber</I><B>:</B><I>newnumber</I>

     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.


</PRE>
<H4>Diagnostics:</H4><PRE>
     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.


</PRE>
<H4>Note:</H4><PRE>
     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", <B>this</B> <B>tree</B> <B>will</B> <B>not</B> <B>be</B> <B>ignored</B> 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 -&gt; /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".


</PRE>
<H4>Caveats:</H4><PRE>
     <I>id</I><B>_</B><I>renumber</I> performs no sanity checking on its input.  If
     differing mappings are given with the same  <I>oldnumber</I>, the
     later one is the only effective one.  Remappings will not be
     performed.  Multiple  <I>oldnumber</I>s can be mapped to the same
     <I>newnumber</I>; 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.


</PRE>
<H4>Examples:</H4><PRE>
          # 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 &lt; file


</PRE>
<H4>Bugs:</H4><PRE>
     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 <I>id</I><B>_</B><I>renumber</I> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>accounts-config(7)</B> - configuring the accounts package
     <B>orphan(8)</B> - look for unowned files
     <B>decomment(1)</B> - remove shell-style comments


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2008, MFCF, CSCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ idregistry command
<!-- <pre>
-H localhost -t accounts 8 idregistry
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     idregistry - send request to the uidregd id registry daemon


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>idregistry</B> {<B>Request</B>|<B>Require</B>|<B>Report</B>|<B>Control</B>} [<B>RegistryHost</B>=]
     [<B>Conformance</B>=None|Advisory|Strict] [<B>Type</B>=User|Group] [<B>name</B>=]


</PRE>
<H4>Where:</H4><PRE>
     <B>RegistryHost</B>=
          specifies the name of the host that registers our user
          and group ids.

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

     <B>Type</B> specifies whether the names and id numbers are for
          userids or groups.

     <B>name</B> 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.


</PRE>
<H4>Description:</H4><PRE>
     <B>idregistry</B> provides a command-line interface to the
     <B>uidregd(8)</B> 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.

     <B>Request</B> and <B>Require</B>
          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 <I>Request</I>s, and will cause a new uid to be assigned
          and registered for <I>Require</I>s.  Except when a new id
          pairing was generated this will not update the "last-
          seen" date in the registry.

     <B>Report</B>
          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".

     <B>Control</B>
          makes a privileged request of a special action of the
          daemon.  Currently available actions (specified by set-
          ting the <I>name</I> parameter) are <B>Die</B> and <B>Cleanup</B>.  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).


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

     <B>IDINUSE</B>
          The reported "number" is already assigned to a differ-
          ent name.

     <B>NAMEINUSE</B>
          The reported "name" is already assigned to a different
          id number.

     <B>UNKNOWN</B>
          The given "name" is not in the registry.

     More serious problems may also be returned:

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

     <B>*NOID</B>
          The reported number field was empty or non-numeric.

     <B>*NOCOLON</B>
          The reported "name:number" didn't contain a colon.


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

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

     <B>Conformance</B>={strict|advisory|none}
          How this region wishes to conform to the registry
          host's standard ids.  "<B>none</B>" means that nothing hap-
          pens.  "<B>strict</B>" means that all new passwd and group
          entries created by the sponsor mechanism or by
          <B>edit_group(8)</B> 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".  "<B>advisory</B>" 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".


</PRE>
<H4>See Also:</H4><PRE>
     <B>uidregd(8)</B> - maintains uid and gid registry database


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2003, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ initialize_users command
<!-- <pre>
-H localhost -t accounts 8 initialize_users
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     initialize_users - update the vendor and xhier entries in
     the data/users file


</PRE>
<H4>Synopsis:</H4><PRE>
     sort  -t :  -k 1,1  users  |  <B>initialize_users</B>  &gt;users.new


</PRE>
<H4>Description:</H4><PRE>
     For each entry in the vendor passwd file that has an exist-
     ing entry in the "/etc/passwd" file, <B>initialize_users</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>users(5)</B>.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/setpw/config/arch/vendor.passwd


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1997,2009 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ make_cifs_exports command
<!-- <pre>
-H localhost -t accounts 8 make_cifs_exports
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     make_cifs_exports - rebuild the links to user cifs_exports
     directories


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>make_cifs_exports</B>


</PRE>
<H4>Description:</H4><PRE>
     The <B>make_cifs_exports</B> 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.


</PRE>
<H4>Options:</H4><PRE>
     None.


</PRE>
<H4>Files Used:</H4><PRE>
     "/software/accounts/data/cifs_exports/all/"
     /u/*/cifs_exports
     /u[0-9]/*/cifs_exports
     /software/accounts/config/local/other_cifs_homes/*/*/cifs_exports


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1998, 2003, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mergefasquotas command
<!-- <pre>
-H localhost -t accounts 8 mergefasquotas
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mergefasquotas - Generate a quotas file based on fragments
     generated by mkquota.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mergefasquotas</B> hostname [<I>fasgroupname</I>]*


</PRE>
<H4>Description:</H4><PRE>
     This command generates a quotas file on the faserver "<B>host-</B>
     <B>name</B>" from quotas file fragments generated by the "<B>mkquota</B>"
     command and defined by "<B>fasgroupname</B>" and then reinitilizes
     quotas on the faserver.


</PRE>
<H4>Note:</H4><PRE>
     This command assumes the faserver has only one volume.


</PRE>
<H4>See Also:</H4><PRE>
     <B>mkquota(8)</B> - set all quotas according to the .../users file.


</PRE>
<H4>Author:</H4><PRE>
     Written in July 2003 by Jason Testart, CSCF, University of
     Waterloo.

</PRE>
<!--
</pre> -->
---++ mkfasquotafile command
<!-- <pre>
-H localhost -t accounts 8 mkfasquotafile
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mkfasquotafile - generate a fas quota file from  a users
     file.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mkfasquotafile</B> [<B>FileSystem</B>=<B>]</B> [<B>DefaultQuota</B>=<B>]</B> [<B>UserFilename</B>=<B>]</B>
     [<B>fasVolume</B>=<B>]</B> [<B>FasHost</B>=<B>]</B>


</PRE>
<H4>Where:</H4><PRE>
     <B>FileSystem</B>=
          specifies the name of the filesystem, as known to the
          relevant FAServer, on which to grant quota.

     <B>DefaultQuota</B>=
          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".

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

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

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


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


</PRE>
<H4>Notes</H4><PRE>
     Normally an automated process will be used to update the
     <I>/software/accounts/data/users</I> file, or equivalent.

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


</PRE>
<H4>Files Used:</H4><PRE>
     /etc/passwd or equivalent
     /software/accounts/data/users


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2008, CSCF, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mkhomes command (Somewhat Important)
%RED% 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.%ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 mkhomes
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mkhomes - create and initialize home directories


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mkhomes</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>mkhomes</B> is normally invoked via the <B>sponsor_accounts(8)</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>realuser(1)</B>, <B>init_home(1)</B>, <B>link_homes(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mkmerge command
<!-- <pre>
-H localhost -t accounts 8 mkmerge
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     mkusers, mkmerge - merge commandline or file data to update
     and create user accounts


</PRE>
<H4>EXAMPLE</H4><PRE>
     <B>mkusers</B> <B>userid</B>

     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.


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>mkmerge</B> [ <B>-a</B> ] [ <B>-e</B> ] [ <B>-f</B> ] [ <B>-m</B> ] [ <B>-u[u]</B> ]
           [ <B>-l</B> uidlen ] [ <B>-k</B> num_fs ] [ <B>-P</B> passwd ] [ <B>-U</B> users ]
           <I>pwd</I><B>_</B><I>merge</I> <I>usr</I><B>_</B><I>merge</I>

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

     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).


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Mkusers</I> 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 <I>mkmerge</I> below.

     <I>Mkmerge</I> merges information contained in the passwd- and
     users-formatted files <I>pwd</I><B>_</B><I>merge</I> and <I>usr</I><B>_</B><I>merge</I> 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.


</PRE>
<H4>NOTE</H4><PRE>
     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}.


</PRE>
<H4>CONFIGURATION OPTIONS</H4><PRE>
     The directories "<I>/software/accounts/config/*/init</I><B>_</B><I>home</I>" 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 "<I>/soft-</I>
     <I>ware/accounts/data/host/standard</I>" 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.


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd                        the password file itself
     /etc/ptmp                          the password lockfile
     /software/accounts/data/users      local additions to passwd
     /u/<I>username</I>                        user home directory
     /u[0-9]+/<I>username</I>                        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


</PRE>
<H4>SEE ALSO</H4><PRE>
     accounts_admin(i), <B>rmusr(8)</B>, <B>undelete(8)</B>, <B>edquota(8)</B>,
     <B>vipw(8)</B>, <B>add_all(8)</B>, <B>.login(5)</B>, <B>.profile(5)</B>

</PRE>
<!--
</pre> -->
---++ mkpw command
<!-- <pre>
-H localhost -t accounts 8 mkpw
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>NAME</H4><PRE>
     mkpw - update the passwd dbm files


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>mkpw</B>


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Mkpw</I> is a kludge used to update the passwd dbm files from
     its source.


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd    the password file itself
     /etc/passwd.pag
     /etc/passwd.dir
     /etc/ptmp password file lock

</PRE>
<!--
</pre> -->
---++ mkquota command
<!-- <pre>
-H localhost -t accounts 8 mkquota
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mkquota - set all quotas according to the .../users file.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mkquota</B> [<B>+TEST</B>] [<B>-Verbose</B>] [<B>fasgroup=...]</B>  [<I>userid</I>]*


</PRE>
<H4>Description:</H4><PRE>
     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 "<B>+test</B>", the output is
     the same, but no actual updates are performed.

     Unless the option "<B>-verbose</B>" 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 "<B>fasgroup</B>" 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 <B>userid</B>s 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 <B>all</B> <B>users</B>
     on the machine, one may create a memberless /etc/group entry
     called "quota_everywhere".


</PRE>
<H4>Configuration:</H4><PRE>
     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 <B>mergefasquotas</B> command.


</PRE>
<H4>Notes:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>
     /etc/passwd
     /software/accounts/data/users
     /software/accounts/config/regional/fashosts
     /software/accounts/config/regional/rquotahosts


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1989, 1998, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mkstudents command
<!-- <pre>
-H localhost -t accounts 8 mkstudents
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>NAME</H4><PRE>
     mkstudents - process the registrar's student file


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>mkstudents</B>     [-g] [term]

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


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Mkstudents</I> 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.


</PRE>
<H4>FILES</H4><PRE>
     /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


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>regtape(8)</B>, <B>add_all(8)</B>, <B>mkmatch(8)</B>, <B>mkstuds(8)</B>, <B>mkpw(8)</B>


</PRE>
<H4>BUGS</H4><PRE>
     Mkstudents does not rebuild any dbm files.

</PRE>
<!--
</pre> -->
---++ mkstuds command
<!-- <pre>
-H localhost -t accounts 8 mkstuds
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->


</PRE>
<H4>NAME</H4><PRE>
     mkstuds - process the registrar's student file


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>mkstuds</B>   [-g] [-h home] [-P pwdfile] [-U usrfile] [term]

     Options:
     <B>-g</B>   delete grads (normally they are not deleted)
     <B>-h</B>   home filesystem
          default: /u[0-9]*  selected for maximum free space
     <B>-P</B>   flag next option as the name of the passwd file
          default: /etc/passwd, /etc/ypsrc/mad/passwd
     <B>-U</B>   flag next option as the name of the users file
          default: /etc/users,  /etc/ypsrc/mad/users
     <B>term</B> 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.


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Mkstuds</I> 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.


</PRE>
<H4>FILES</H4><PRE>
     /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


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>regtape(8)</B>, <B>add_all(8)</B>, <B>mkmatch(8)</B>, <B>mkusers(8)</B>


</PRE>
<H4>BUGS</H4><PRE>
     Bugs?

</PRE>
<!--
</pre> -->
---++ mkusers command
<!-- <pre>
-H localhost -t accounts 8 mkusers
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     mkusers, mkmerge - merge commandline or file data to update
     and create user accounts


</PRE>
<H4>EXAMPLE</H4><PRE>
     <B>mkusers</B> <B>userid</B>

     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.


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>mkmerge</B> [ <B>-a</B> ] [ <B>-e</B> ] [ <B>-f</B> ] [ <B>-m</B> ] [ <B>-u[u]</B> ]
           [ <B>-l</B> uidlen ] [ <B>-k</B> num_fs ] [ <B>-P</B> passwd ] [ <B>-U</B> users ]
           <I>pwd</I><B>_</B><I>merge</I> <I>usr</I><B>_</B><I>merge</I>

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

     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).


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Mkusers</I> 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 <I>mkmerge</I> below.

     <I>Mkmerge</I> merges information contained in the passwd- and
     users-formatted files <I>pwd</I><B>_</B><I>merge</I> and <I>usr</I><B>_</B><I>merge</I> 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.


</PRE>
<H4>NOTE</H4><PRE>
     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}.


</PRE>
<H4>CONFIGURATION OPTIONS</H4><PRE>
     The directories "<I>/software/accounts/config/*/init</I><B>_</B><I>home</I>" 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 "<I>/soft-</I>
     <I>ware/accounts/data/host/standard</I>" 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.


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd                        the password file itself
     /etc/ptmp                          the password lockfile
     /software/accounts/data/users      local additions to passwd
     /u/<I>username</I>                        user home directory
     /u[0-9]+/<I>username</I>                        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


</PRE>
<H4>SEE ALSO</H4><PRE>
     accounts_admin(i), <B>rmusr(8)</B>, <B>undelete(8)</B>, <B>edquota(8)</B>,
     <B>vipw(8)</B>, <B>add_all(8)</B>, <B>.login(5)</B>, <B>.profile(5)</B>

</PRE>
<!--
</pre> -->
---++ orphan command
<!-- <pre>
-H localhost -t accounts 8 orphan
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     orphan - walk a directory tree looking for unowned files


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>orphan</B> [<B>+NFS</B>] [<I>directory</I>]...


</PRE>
<H4>Description:</H4><PRE>
     <B>Orphan</B> 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
     <B>+NFS</B> 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 <B>decomment(1)</B>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.)


</PRE>
<H4>Configuration:</H4><PRE>
     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".


</PRE>
<H4>Note:</H4><PRE>
     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",
     <B>this</B> <B>tree</B> <B>will</B> <B>not</B> <B>be</B> <B>ignored</B> 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 -&gt; /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".


</PRE>
<H4>See Also:</H4><PRE>
     <B>accounts-config(7)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1994, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ rmallusr command (VERY IMPORTANT)
<!-- <pre>
-H localhost -t accounts 8 rmallusr
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     rmallusr - do final removal of deleted userids and their
     files.


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>rmallusr</B>


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <B>rmallusr</B> 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`<I>absolute</I> /u/.`", "/backup`<I>absolute</I> /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.


</PRE>
<H4>FILES</H4><PRE>
     Log files are left under "/software/accounts/logs/.".


</PRE>
<H4>BUGS</H4><PRE>
     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.

</PRE>
<!--
</pre> -->
---++ rmclean command
<!-- <pre>
-H localhost -t accounts 8 rmclean
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     rmclean - clean out files for deleted users on regional
     clients


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>rmclean</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>rmclean</B> is normally called by <B>rmallusr(8)</B> 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.


</PRE>
<H4>Options:</H4><PRE>
     None.


</PRE>
<H4>Files Used:</H4><PRE>
     "/software/accounts/data/temp_regional/delete_uids"
     "/software/accounts/data/temp_regional/delete_userids"


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2003, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ rmusr command
<!-- <pre>
-H localhost -t accounts 8 rmusr
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     rmusr - remove user accounts


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>rmusr</B> <B>userid</B>


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Rmusr</I> 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.


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd
     /etc/shells_system
     /usr/accounts/logs/change


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>undelete(8)</B>, <B>rmallusr(8)</B>

</PRE>
<!--
</pre> -->
---++ setpasswd command
<!-- <pre>
-H localhost -t accounts 8 setpasswd
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     setpasswd - change some fields in the passwd file.


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>setpasswd</B> <B>-help</B>

     <B>This</B> <B>command</B> <B>has</B> <B>been</B> <B>superseded</B> by <B>password(1)</B>, <B>chfn(1)</B>,
     and <B>chsh(1)</B>.


</PRE>
<H4>DESCRIPTION</H4><PRE>
     T.B.A.

</PRE>
<!--
</pre> -->
---++ stripnames command
<!-- <pre>
-H localhost -t accounts 8 stripnames
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     stripnames - strip entries and members from
     /etc/{group,passwd} type files


</PRE>
<H4>Synopsis</H4><PRE>
     <B>stripnames</B> <B>entry</B> [<B>Input</B>=-] [<B>FieldNumber</B>=0] [<B>Name-</B>
     <B>File</B>=/dev/null] [[<B>name</B>=]null]* [<B>IfMember</B>=kill<B>me]</B>
     <B>stripnames</B> <B>member</B> [<B>Input</B>=-] [<B>FieldNumber</B>=0] [<B>Name-</B>
     <B>File</B>=/dev/null] [[<B>name</B>=]null]*

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

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

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

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

     [<B>IfMember</B>=kill<B>me]</B>
          For the "<I>stripnames</I>"entry command, the entry will be
          stripped only if the given name is in the list in field
          position "FieldNumber".


</PRE>
<H4>Examples:</H4><PRE>
          # 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 \
          &gt;/etc/group.lock

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

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


</PRE>
<H4>Description:</H4><PRE>
     <B>stripnames</B> is invoked with one of two subcommands.

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

     The <B>entry</B> subcommand causes all lines whose first colon-
     separated field is the same as any of the given "<B>name</B>"s to
     be deleted.  If the "<B>IfMember</B>" 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 "<B>FieldNumber</B>"
     field.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1999, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ undelete command
<!-- <pre>
-H localhost -t accounts 8 Undelete
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>NAME</H4><PRE>
     undelete - restore user accounts deleted by rmusr


</PRE>
<H4>SYNOPSIS</H4><PRE>
     <B>undelete</B> <B>userid</B>


</PRE>
<H4>DESCRIPTION</H4><PRE>
     <I>Undelete</I> 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.


</PRE>
<H4>FILES</H4><PRE>
     /etc/passwd
     /etc/shells_system
     /usr/accounts/logs/change


</PRE>
<H4>SEE ALSO</H4><PRE>
     <B>rmusr(8)</B>, <B>rmallusr(8)</B>

</PRE>
<!--
</pre> -->
---++ xhier_admin command
<!-- <pre>
-H localhost -t accounts 8 xhier_admin
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
     [<B>OBSOLETE:</B> <B>use</B> <B>`hostin</B> <B>group=admin_master`</B>]


</PRE>
<H4>Name:</H4><PRE>
     xhier_admin - return the name of the xhier admin server


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>xhier_admin_server</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>xhier_admin_server</B> checks the local machine's configuration
     and reports the name of its xhier admin server.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/xhier/config/local/allowed-types


</PRE>
<H4>Bugs:</H4><PRE>
     This command doesn't belong in the accounts package.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ xhier_admin_server command
<!-- <pre>
-H localhost -t accounts 8 xhier_admin_server
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
     [<B>OBSOLETE:</B> <B>use</B> <B>`hostin</B> <B>group=admin_master`</B>]


</PRE>
<H4>Name:</H4><PRE>
     xhier_admin - return the name of the xhier admin server


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>xhier_admin_server</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>xhier_admin_server</B> checks the local machine's configuration
     and reports the name of its xhier admin server.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/xhier/config/local/allowed-types


</PRE>
<H4>Bugs:</H4><PRE>
     This command doesn't belong in the accounts package.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ xhier_regional_clients command
%RED% An understanding of the regional clients concept is important for understanding the basis of much of the old accounts maintenance system.  %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts 8 xhier_regional_clients
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
     <B>[</B>OBSOLETE: Superseded by `hostin group=regional_clients`<B>]</B>


</PRE>
<H4>Name:</H4><PRE>
     xhier_regional_clients - return the name(s) of all clients
     in the region


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>xhier_regional_clients</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>xhier_regional_clients</B> 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.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/data/regional-clients/<I>&lt;hostname&gt;</I>


</PRE>
<H4>Bugs:</H4><PRE>
     The returned hostnames are the same as that returned by the
     <B>hostname(1)</B> 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.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ xhier_regional_server command
<!-- <pre>
-H localhost -t accounts 8 xhier_regional_server
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
     [<B>OBSOLETE:</B> <B>use</B> <B>`hostin</B> <B>group=regional_server`</B>]


</PRE>
<H4>Name:</H4><PRE>
     xhier_regional_server - return the name of the xhier
     regional server


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>xhier_regional_server</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>xhier_regional_server</B> checks the local machine's configura-
     tion and reports the name of its xhier regional server.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/data/regional-server/<I>&lt;hostname&gt;</I>


</PRE>
<H4>Bugs:</H4><PRE>
     The returned hostname is the same as that returned by the
     <B>hostname(1)</B> 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.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ accounts administration policy
<!-- <pre>
-H localhost -t accounts i accounts_admin
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name</H4><PRE>
     Accounts_Admin - Account Administration Policy


</PRE>
<H4>Terminology:</H4><PRE>
     A "<B>userid</B>" is a name used to identify a computer user, inde-
     pendent of its existence on any particular machine.

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


</PRE>
<H4>Userid Creation:</H4><PRE>
     For each administration, there will be one central registry
     containing all userids issued by that administration.

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

     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".


</PRE>
<H4>Passwords:</H4><PRE>
     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 <I>cs123</I>, one should not
     give an explicit password to the account, but use the
     account's ".rhosts" file to grant access to specific users.


</PRE>
<H4>Account Accounting:</H4><PRE>
     <B>No</B> <B>one</B> <B>should</B> <B>ever</B> <B>create</B> <B>an</B> <B>account</B> <B>on</B> <B>any</B> <B>machine</B> <B>without</B>
     <B>notifying</B> <B>the</B> <B>administration</B> <B>of</B> <B>the</B> <B>fact</B> <B>and</B> <B>including</B>
     <B>details</B> <B>as</B> <B>to</B> <B>who</B> <B>is</B> <B>sponsoring</B> <B>the</B> <B>account.</B>

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


</PRE>
<H4>Warning:</H4><PRE>
     Accounts that were not created following these rules may be
     disabled or removed by the administration (or by automated
     software) without warning.


</PRE>
<H4>Summary:</H4><PRE>
     In general <B>it</B> <B>is</B> <B>always</B> <B>best</B> <B>to</B> <B>ask</B> <B>the</B> <B>central</B> <B>administra-</B>
     <B>tion</B> <B>to</B> <B>create</B> <B>accounts</B> <B>rather</B> <B>than</B> <B>attempting</B> <B>it</B> <B>oneself.</B>


</PRE>
<H4>Account Creation:</H4><PRE>
     <B>No</B> <B>one</B> <B>should</B> <B>ever</B> <B>create</B> <B>an</B> <B>account</B> <B>on</B> <B>any</B> <B>machine</B> <B>without</B>
     <B>first</B> <B>verifying</B> <B>that</B> <B>the</B> <B>userid</B> <B>is</B> <B>already</B> <B>registered</B> <B>to</B> <B>the</B>
     <B>same</B> <B>person</B> <B>for</B> <B>whom</B> <B>the</B> <B>account</B> <B>is</B> <B>intended.</B>

     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 <B>uwdir(1)</B> 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 <B>finger(1)</B>).

     If you are going to manage your own accounts, you must be in
     group "accounts", and should set your search rules with the
     <B>showpath(1)</B> 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 <B>rmallusr(8)</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     userids(i),
     mfcf-policy(i),


</PRE>
<H4>Copyright:</H4><PRE>
     (C) 1992, 1996, MF, University of Waterloo

</PRE>
<!--
</pre> -->
---++ groups information
<!-- <pre>
-H localhost -t accounts i groups
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     groups - how to use groups on MFCF supported machines.


</PRE>
<H4>Description:</H4><PRE>
     When your new account is created, a group is assigned to
     your home directory (by default group "<B>none</B>") and one or
     more groups are assigned to your userid (by default group
     "<B>everyone</B>").  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 <B>chgrp(1)</B> 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 "<B>source</B>" 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 "<B>cs123_45</B>", 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, <B>fixclassperms(1)</B>, 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
     "<I>$UMASK</I>" 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 "<B>$HOME/.cshrc</B>" file, so that all
     files that you ever create will allow writing for members of
     their group, but not for anyone else.


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


</PRE>
<H4>Copyright:</H4><PRE>
     (C) 1988, 1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
%BR%
%BR%
---++ check_userids command
<!-- <pre>
-H localhost -t accounts-userids 8 check_userids
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     check_userids - check Userids file.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>check_userids</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>check_userids</B> checks that the Userids file is valid.


</PRE>
<H4>Files</H4><PRE>
     /software/accounts-userids/data/Userids


</PRE>
<H4>Bugs</H4><PRE>
     You cannot specify an alternate file to check.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1991, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ id-to-userid command
<!-- <pre>
-H localhost -t accounts-userids 8 id-to-userid
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     id-to-userid - filter to map ID numbers to userids in colon-
     separated fields


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>id-to-userid</B> [<B>Id</B>=1] [<B>Userid</B>=0]


</PRE>
<H4>Examples:</H4><PRE>
          % cat input
          one:two:71212246:four:five
          % id-to-userid &lt;input id=3
          one:two:rbutterworth:four:five
          % id-to-userid &lt;input id=3 u=3
          one:two:rbutterworth:71212246:four:five
          % id-to-userid &lt;input id=3 u=-4
          one:two:71212246:rbutterworth:five
          % id-to-userid &lt;input id=2
          one:?:71212246:four:five
          % id-to-userid &lt;input id=3 u=10
          one:two:71212246:four:five:::::rbutterworth


</PRE>
<H4>Options:</H4><PRE>
     [<B>Id</B>=1]
          Field number (origin 1) of the input ID number.  IDs
          can be watcard numbers (71212246), uwdir numbers
          (P-35580), etc.

     [<B>Userid</B>=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.


</PRE>
<H4>Description:</H4><PRE>
     <B>id-to-userid</B> 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 "<B>Id</B>" 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.


</PRE>
<H4>Files:</H4><PRE>
     /software/accounts-userids/data/Userids


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2006, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ isuser command
<!-- <pre>
-H localhost -t accounts-userids 8 isuser
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     isuser - check if a user id is in a list of ids


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>isuser</B> known_id id_1 id_2 id_3 ...


</PRE>
<H4>Example:</H4><PRE>
     if ( { isuser $user1 91999123 joe 11119876 } ) then
          echo $user1 matched at least one of the other ids
     endif


</PRE>
<H4>Description:</H4><PRE>
     <B>isuser</B> looks in the "Userids" file and finds all knows ids
     and userids for each of the ids on the command line.


</PRE>
<H4>Returns:</H4><PRE>
     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.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts-userids/data/Userids


</PRE>
<H4>See Also:</H4><PRE>
     <B>realuser(1)</B>, <B>sameuser(1)</B>, <B>truncuser(1)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ update_userids command
<!-- <pre>
-H localhost -t accounts-userids 8 update_userids
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     update_userids - update the Userids database with uwdir data


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>update_userids</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>update_userids</B>

     This program normally runs from the crontab.

     It uses <B>uwdir_update(8)</B> 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".


</PRE>
<H4>Files:</H4><PRE>
     watserv1:/sagroup/UWdir-II/Extract /software/accounts-
     userids/data/Userids /software/accounts/logs/userids_update


</PRE>
<H4>See Also:</H4><PRE>
     <B>uwdir_update(8)</B>, <B>check_userids(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2002, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ uwdir_update command
<!-- <pre>
-H localhost -t accounts-userids 8 uwdir_update
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     uwdir_update - merge UWdir data into the Userids database


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>uwdir_update</B>
     [<B>Extract=</B>/software/accounts-userids/data/work/Extract]
     [<B>Userids=</B>/software/accounts-userids/data/Userids]


</PRE>
<H4>Options:</H4><PRE>
     <B>Extract</B>=/software/accounts-userids/data/work/Extract
          Dump of UWdir data to be merged.

     <B>Userids</B>=/software/accounts-userids/data/Userids
          Master Userids database.

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


</PRE>
<H4>Description:</H4><PRE>
     <B>uwdir_update</B> 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.


</PRE>
<H4>Output:</H4><PRE>
     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 -&gt; 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.


</PRE>
<H4>Handling problems:</H4><PRE>
     <B>Fatal</B> errors mean that no update happened.  The cause needs
     to be corrected as soon as possible.

     Non-fatal <B>Error</B>s 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.

     <B>IST</B> <B>errror</B>s 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>update_userids(8)</B>, <B>check_userids(8)</B>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2002, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ .classlist command
<!-- <pre>
-H localhost -t accounts_client 5 .classlist
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     classlist, .classlist - list of students registered in a
     class.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>/u/</B>&lt;classname&gt;<B>/.classlist</B>

     <B>Supported</B> <B>on</B> <B>undergrad.math</B> <B>only.</B>


</PRE>
<H4>Format:</H4><PRE>
     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 <B>decomment(1)</B> to extract the
     data).

     <B>Id</B> <B>Number</B>
          the student id number associated with the userid.

     <B>Userid</B>
          the standard userid assigned to the account.

     <B>Name</B> 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.

     <B>Lecture</B>
          the lecture section that the student is registered in.

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

     <B>Plan</B> the plan that the student is registered in.

     <B>Group</B>
          the group (i.e. faculty) that the student is registered
          in.

     <B>Year</B> the current year the student is registered in.

     <B>Degree</B>
          the degree the student is currently registered in.

     <B>Initials</B>
          the given initials of the student (as currently
          recorded by the Registrar).

     <B>Family</B>
          the student's family name.

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

     <B>Time</B> the student's attendance (P-partime, F-fulltime).

     <B>Session</B>
          the session that the student is registered in.

     <B>Sections</B>
          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".

     <B>Other</B>
          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.


</PRE>
<H4>Description:</H4><PRE>
     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.


</PRE>
<H4>Access:</H4><PRE>
     The file for say class cs123 will be called
     "/u/cs123/.classlist" and will be owned by the userid
     "<I>cs123</I>" and the group "<I>cs123</I>".  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
     "<I>.rhosts</I>" file, which allows them to <B>rlogin(1c)</B> to the
     account.


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


</PRE>
<H4>See Also:</H4><PRE>
     <B>decomment(1)</B>, <B>cut(1)</B>, <B>cl2sc(1)</B>.


</PRE>
<H4>Bugs:</H4><PRE>
     For students registered in more than one department or fac-
     ulty, only one of their registrations will appear in the
     file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992,1996,2000,2001 MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ account_update command
<!-- <pre>
-H localhost -t accounts_client 8 account_update
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     account_update - merge account information with /etc/passwd
     etc.


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>account_update</B> [<B>+Groupcheck</B>] [<B>Update=</B>-]
     [<B>NewGroup</B>=-] [<B>NewPasswd</B>=-] [<B>NewUsers</B>=-]
     [<B>Group=</B>/u/rbutterworth/test/group]
     [<B>Passwd=</B>/u/rbutterworth/test/passwd]
     [<B>Users=</B>/u/rbutterworth/test/users]


</PRE>
<H4>Description:</H4><PRE>
     <B>account_update</B> is normally invoked from <B>sponsor_accounts(8)</B>.

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

     <B>Group</B> is normally "/etc/group", <B>Passwd</B> is normally
     "/etc/passwd", and <B>Users</B> 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.

     +<B>Groupcheck</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>sponsor_accounts(8)</B>, <I>/usr/include/accounts/resources.h</I>


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996 MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ cl2sc command
<!-- <pre>
-H localhost -t accounts_client 1 cl2sc
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
NAME
  cl2sc - filter to convert a ".classlist" file into "sc" form

SYNOPSIS
  <B>cl2sc</B>

EXAMPLES
       cayley% cl2sc &lt;~cs456/.classlist &gt;list
       cayley% sc list

DESCRIPTION
  <I>cl2sc</I> is a filter that converts a .<I>classlist</I> file as produced by the
  <I>accounts</I> package in the home directories of course accounts into a file
  that the <I>sc</I> 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

  <B>~</B><I>CourseNumber</I><B>/.classlist</B>
       - where class list files are kept.

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

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

</PRE>
<!--
</pre> -->
---++ classgroup command
<!-- <pre>
-H localhost -t accounts_client 1 classgroup
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     classgroup - start a subshell in a class project group


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>classgroup</B> groupnumber [<B>'command</B> <B>and</B> <B>args'</B>]


</PRE>
<H4>Example:</H4><PRE>
     [201]% wmi
     cs123@cayley (Group everyone) on ttyub at /u1/cs123
     [202]% groups
     everyone ... cs123 ...
     [203]% classgroup 45
     1&gt;[57]% wmi
     cs123@cayley (Group everyone) on ttyub at /u1/cs123
     1&gt;[58]% groups
     everyone ... cs123 ... cs123_45
     1&gt;[59]% exit
     [204]% /* Back where we started */


</PRE>
<H4>Description:</H4><PRE>
     The <B>classgroup</B> 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".


</PRE>
<H4>See Also:</H4><PRE>
     <B>fixclassperms(1)</B>
     <B>userinfo(1)</B>
     <I>groups</I>(i)


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, 1996, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ classlist command
<!-- <pre>
-H localhost -t accounts_client 5 classlist
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     classlist, .classlist - list of students registered in a
     class.


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>/u/</B>&lt;classname&gt;<B>/.classlist</B>

     <B>Supported</B> <B>on</B> <B>undergrad.math</B> <B>only.</B>


</PRE>
<H4>Format:</H4><PRE>
     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 <B>decomment(1)</B> to extract the
     data).

     <B>Id</B> <B>Number</B>
          the student id number associated with the userid.

     <B>Userid</B>
          the standard userid assigned to the account.

     <B>Name</B> 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.

     <B>Lecture</B>
          the lecture section that the student is registered in.

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

     <B>Plan</B> the plan that the student is registered in.

     <B>Group</B>
          the group (i.e. faculty) that the student is registered
          in.

     <B>Year</B> the current year the student is registered in.

     <B>Degree</B>
          the degree the student is currently registered in.

     <B>Initials</B>
          the given initials of the student (as currently
          recorded by the Registrar).

     <B>Family</B>
          the student's family name.

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

     <B>Time</B> the student's attendance (P-partime, F-fulltime).

     <B>Session</B>
          the session that the student is registered in.

     <B>Sections</B>
          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".

     <B>Other</B>
          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.


</PRE>
<H4>Description:</H4><PRE>
     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.


</PRE>
<H4>Access:</H4><PRE>
     The file for say class cs123 will be called
     "/u/cs123/.classlist" and will be owned by the userid
     "<I>cs123</I>" and the group "<I>cs123</I>".  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
     "<I>.rhosts</I>" file, which allows them to <B>rlogin(1c)</B> to the
     account.


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


</PRE>
<H4>See Also:</H4><PRE>
     <B>decomment(1)</B>, <B>cut(1)</B>, <B>cl2sc(1)</B>.


</PRE>
<H4>Bugs:</H4><PRE>
     For students registered in more than one department or fac-
     ulty, only one of their registrations will appear in the
     file.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992,1996,2000,2001 MFCF, University of Water-
     loo.

</PRE>
<!--
</pre> -->
---++ expire_accounts command
<!-- <pre>
-H localhost -t accounts_client 8 expire_accounts
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     expire_accounts - warn and/or disable expired accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>expire_accounts</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>expire_accounts</B> 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.


</PRE>
<H4>Note:</H4><PRE>
     This command is not privileged but should be run as root.


</PRE>
<H4>Files Used:</H4><PRE>
     /software/accounts/data/users -- state of regional accounts
     /software/accounts/config/regional/grace -- set grace period


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992,1999, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ fixclassperms command
<!-- <pre>
-H localhost -t accounts_client 1 fixclassperms
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     fixclassperms - fix the permissions on a student's course
     directory


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>fixclassperms</B> <I>userid</I>


</PRE>
<H4>Description:</H4><PRE>
     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 <B>fixclassperms</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>userinfo(1)</B>
     <B>classgroup(1)</B>
     <I>groups</I>(i)


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1993, 1997, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ link_homes command
<!-- <pre>
-H localhost -t accounts_client 8 link_homes
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     link_homes - create symlinks to home directories


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>link_homes</B> [{+|-}<B>NFS</B>] <I>directory</I>


</PRE>
<H4>Description:</H4><PRE>
     <B>link_homes</B> 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 "<B>directory</B>" containing the new links being
     "/u".

     To avoid accidents, by default an error message will appear
     if the directory is nfs mounted.  The "<B>+NFS</B>" option causes
     an error unless the directory is nfs mounted, while the
     "<B>-NFS</B>" option causes the progam to silently exit if the
     directory is nfs mounted.


</PRE>
<H4>Configuration:</H4><PRE>
     The file "/software/accounts/config/local/link_homes" may
     contain default option flags (currently only "+NFS"), one
     per line.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992, 1998, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mac_pw_sync command
<!-- <pre>
-H localhost -t accounts_client 8 mac_pw_sync
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mac_pw_sync  - synchronizes passwords on a Mac with the cur-
     rent UNIX host


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mac_pw_sync</B> [+<I>Debug</I>] [hostname=]<I>mac-hostname</I>*


</PRE>
<H4>Description:</H4><PRE>
     <B>mac_pw_sync</B> 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 <B>+Debug</B> flag displays the resulting update commands with-
     out actually executing them.


</PRE>
<H4>See Also:</H4><PRE>
     <B>mac_to_passwd(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2005, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ mac_to_passwd command
<!-- <pre>
-H localhost -t accounts_client 8 mac_to_passwd
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     mac_to_passwd - converts a Mac dump to /etc/passwd format


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>mac_to_passwd</B> [no arguments]


</PRE>
<H4>Description:</H4><PRE>
     <B>mac_to_passwd</B> 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 (<I>class</I>, <I>change</I>, and
     <I>expire</I>) between the <I>gid</I> and <I>gecos</I> fields.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2005, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ ppp_dialup_update command (PRUNED)
%RED% Anything related to the _ppp_ (telephone modem) type of resources was never used in recent memory. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts_client 8 ppp_dialup_update
-->
<!--
</pre> -->
---++ ppp_update command (PRUNED)
%RED% Anything related to the _ppp_ (telephone modem) type of resources was never used in recent memory. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts_client 8 ppp_update
-->
<!--
</pre> -->
---++ sponsor_accounts command
<!-- <pre>
-H localhost -t accounts_client 8 sponsor_accounts
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     sponsor_accounts - update the sponsored accounts


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>sponsor_accounts</B> [+<B>Force</B>] [+<B>GroupCheck</B>]


</PRE>
<H4>Description:</H4><PRE>
     <B>sponsor_accounts</B> 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 +<B>Force</B> 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
     (<I>account</I><B>_</B><I>update</I>).

     Then missing home directories are created (<I>mkhomes</I>), sym-
     links to home directories from under /u are updated
     (<I>link</I><B>_</B><I>homes</I>), and disk quotas are updated (<I>mkquota</I>).

     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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>account_update(8)</B>, <B>mkquota(8)</B>, <B>mkhomes(8)</B>, <B>link_homes(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1996, 2001, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ sponsor_aliases command
<!-- <pre>
-H localhost -t accounts_client 8 sponsor_aliases
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     sponsor_aliases - update the sponsored mail aliases


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>sponsor_aliases</B> [+<B>Force</B>]


</PRE>
<H4>Description:</H4><PRE>
     <B>sponsor_aliases</B> 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
     +<B>Force</B> 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.


</PRE>
<H4>See Also:</H4><PRE>
     <B>sponsor_accounts(8)</B>, <B>account_update(8)</B>, <B>mkquota(8)</B>,
     <B>mkhomes(8)</B>, <B>link_homes(8)</B>.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 2004, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ sponsor_ppp command (PRUNED)
%RED% Anything related to the _ppp_ (telephone modem) type of resources was never used in recent memory. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts_client 8 sponsor_ppp
-->
<!--
</pre> -->
---++ usergroups command
<!-- <pre>
-H localhost -t accounts_client 8 usergroups
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     usergroups - creates a private group for each user


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>usergroups</B> [[<B>groups</B>=]<I>everyone</I>]*


</PRE>
<H4>Description:</H4><PRE>
     <B>usergroups</B> 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.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, 2003, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ userid_status command
<!-- <pre>
-H localhost -t accounts_client 8 userid_status
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     userid_status - show the status of all userids on this host


</PRE>
<H4>Synopsis:</H4><PRE>
     servers/<B>userid_status</B>


</PRE>
<H4>Description:</H4><PRE>
     <B>userid_status</B> 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
     "<I>userid:status</I>", 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.


</PRE>
<H4>Note:</H4><PRE>
     This program is normally called only by <B>get_userid_status(8)</B>
     in the <I>accounts-master</I> package.


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1995, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->
---++ userinfo command (Reasonably Important)
%RED% _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. %ENDCOLOR%
<!-- <pre>
-H localhost -t accounts_client 1 userinfo
-->
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->

</PRE>
<H4>Name:</H4><PRE>
     userinfo - show information about a user


</PRE>
<H4>Synopsis:</H4><PRE>
     <B>userinfo</B> [userid|idnumber] [{+|-}Sponsors]


</PRE>
<H4>Description:</H4><PRE>
     The <B>userinfo</B> 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 "<I>root</I>", and the groups "<I>operator</I>" and "<I>accounts</I>"
     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 -<B>Sponsors</B> 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.


</PRE>
<H4>Notes:</H4><PRE>
     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 "<I>help</I>", 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 "<I>help</I>" userid.


</PRE>
<H4>Exit Status:</H4><PRE>
     The program exits with a status of 1 if no information at
     all can be found about the user on this machine.


</PRE>
<H4>Files Used:</H4><PRE>
     "/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"


</PRE>
<H4>Copyright:</H4><PRE>
     Copyright (C) 1992, 1998, MFCF, University of Waterloo.

</PRE>
<!--
</pre> -->

-- Main.AdrianPepper - 2019-02-05
Topic revision: r3 - 2019-02-11 - AdrianPepper
Information in this area is meant for use by CSCF staff and is not official documentation, but anybody who is interested is welcome to use it if they find it useful.
Other Webs
My links
- People
- CERAS
- WatForm
- Tetherless lab
- Ubuntu Main.HowTo
- eDocs
- RGG NE notes
- RGG
- CS infrastructure
- Grad images
Edit