Date: Mon, 9 Aug 1999 11:24:43 -0700 (PDT)
From: Hugh Sheets
To: jbranom@cac.washington.edu, dorish@cac.washington.edu,
hornung@cac.washington.edu
Cc: hugh@cac.washington.edu, remmers@cac.washington.edu,
stenvik@cac.washington.edu
Subject: Austen....
With Jeanne's running of billing on her NT ACCESS client, the
decommissioning of Austen has taken a giant step forward. I'm hoping
to establish a plan and schedule so we are all on the same page and
in agreement, so here's a draft open for commments/suggestions/changes:
1. In a few days, we should all know (hopefully by not hearing otherwise)
that the new billing worked fine - CTIs were accepted into the FAS
system, invoice file accepted by Cashiers Office, slightly "new look"
well received by customers, etc. We are committed to fixing anything
that needs fixing to ensure this new billing is used and *not* falling
back to the parallel billing Jeanne ran on Austen.
2. Nobody should be doing anything on Austen in production mode - Jeanne
should not be doing any parallel billing, no file updating, no data
entry by C&CI, etc. From July 1 forward, nothing on Austen is used,
and from now on anything done on Austen is wasted effort. No EOQ,
DAY1/10, CHARGES for July 1 on, *BUT* GENCL, the class list generator,
and ADD used to increase limits for a whole class, will still be used
to finish out Summer quarter, ending Aug 20. For Fall quarter, Bill
Shirey will be providing a replacement GENCL system and that is all the
detail I know about it. We still need to come up with replacement
ADD and CHARGES procedures, which we will have soon.
There are some automatic programs still running on Austen and a couple
of odds and ends to clean up, but we plan to start shutting these down.
Please get the word out to all of C&CI to not use Austen for anything
but GENCL and ADD, and these only until Aug 20. If we have overlooked
anything we need to know ASAP.
3. We have a couple of clients to get written, which we are working on
now - EOQ, ADD, CHARGES as mentioned, and a client for C&CI to
add/change billing records like email accounts. Until this last one
is done, Jeanne will bear the data entry burden as the only one in C&CI
with a billing client on her PC.
4. As Jeanne's schedule allows, she can update her billing documention
(the csbiz web site) so the new process is documented.
5. Tom will document and archive the new ACCESS billing client.
6. Plan on reviews of everything to get us all to a point where we
all can say it is "done for now" - at a point where we have covered
all issues we have. Of course this will never really be done, but
when we have gone through a couple of quarters and billing cycles
I hope we can have everything patched up to where we can set this
aside for a while.
Date: Wed, 4 Aug 1999 13:35:48 -0700 (PDT)
From: Hugh Sheets
To: hornung@u.washington.edu, hugh@cac.washington.edu, ken@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Subject: Highlights of 99/07/29 Accounting meeting....
From 99/07/29 Accounting meeting....
Hugh, Tom, and Tracy met to review our status on getting off Austen.
A couple of tasks are not completely up and running elsewhere, but
they will be by the next scheduled running.
Billing: Next week, Jeanne will run production billing for July 1999
using her ACCESS client authored by Tom. She will also be running
most of July's billing on Austen in parallel, but we will not be
using any Austen-based billing. This will be the last time billing
runs on Austen.
EOQ: Still is needed, and not yet moved. Tracy has a plan to have
EOQ running on Daffy, and hopefully set up to run automatically
on a pre-established schedule. We can project out these dates for
quite a while and eliminate human interaction. At the least,
the human-run Daffy replacement needs to be operational by Sept 20.
DAY1/10: Was run for the last time in June. GENCL and ADD use the
data produced by DAY1/10.
GENCL: The Austen-based class list generator uses the data produced by
DAY1/10. We are counting on Bill Shirey's Class List replacement
for Fall 1999.
ADD: The Austen-based procedure to increase limits for an entire class.
Tom will create a Daffy-based web page for C&CI which will make
the CDF file Ken uses to increase limits. This needs to be
operational by Sept 27.
CHARGES: The Austen-based procedure used by selected Budget Administrators
and individual users to generate a detailed breakdown of billing
charges. This detailed breakdown is now generated by default by the
new ACCESS-based billing, and will be sent out with the invoices and
CTIs. Tom will create a database table of UWnetIDs of people
authorized to run CHARGES for a given budget number (we need to be
able allow multiple UWnetIDs/budget number) and individual UWnetIDs
will be able to run CHARGES for themselves. CHARGES will be a
web-based tool, and either Tom or Tracy will build it. CHARGES will
not be able to be run on Austen for billing from July 1 on.
STDDIR.A16: Thss file is sent to Austen by Li nightly, and in turn is
grabbed by the A series to pass back email addresses to the A series.
Tom is producing this file on Vitcos and is waiting on Bill Shirey to
identify which Vitcos account should be allowed to read it.
Other Austen procedures continue to run, but as far as we can tell are
not being used and are poised for shutdown. We plan to stop running
continuous procedures and observe consequences.
Date: Thu, 24 Jun 1999 14:03:39 -0700 (PDT)
From: Hugh Sheets
To: hornung@u.washington.edu, hugh@cac.washington.edu, ken@cac.washington.edu,
pete@cac.washington.edu, remmers@cac.washington.edu,
stenvik@cac.washington.edu
Cc: deroest@cac.washington.edu, drr@cac.washington.edu
Subject: Highlights of 99/06/17 Accounting meeting and followups....
From 99/06/17 Accounting meeting and followups....
We reviewed our position with regards to Austen's decommission. EOQ was
run on Austen for the last time 6/14, DAY1 is scheduled for the last
running 6/18, the first day of Summer quarter, and DAY10's last run will be
probably July 6. Jeanne has completed the running of May's billing. The
time line shows June's billing will be run in early July, and it is our
goal to run Tom's new billing, but run it in parallel to the old Austen
billing. The end/beginning of the biennium is June 30/July 1, so we
certainly want to be running billing for the new biennium on the new
billing system. This would be the production billing run in early August
for July's billing. We will not be running EOQ/DAY1/10 on Austen after
this Summer quarter.
Specifics:
- Tracy compiled a list of Austen procedures that are not specifically
commented as obsolete so *could* still be running. We are picking
through the list examining them.
- Tom is single-handedly writing the new billing and is virtually done.
Hugh will work with Jeanne to test this. The Cashier's Office (Cindy
Gregovich, Austen account "CASHIER") has been using Austen to fetch a
file (disk$a:[cashier]ucsinv.xxx) created by our monthly billing for
invoices send to external addresses. They still need the file, but we
can email it to Cindy from anywhere - they don't need Austen in
particular.
- EOQ: Closes out a quarter, and is still being used. EOQ notifies
Ken who resets quarterly accumulation fields (assets). I believe
EOQ also removes the galaxy CPF and CDF files used to modify
accounts enrolled in a class when the quarter ends. Tracy will
craft a daffy EOQ to do the same thing before Sept 20, the next
scheduled run of EOQ.
- DAY1/10: Process the EDF.FUL file of student enrollment data ftp-ed
from the A-Series. The only things we are aware of that use the EDF
on Austen anymore are GENCL, the Class List generator, and ADD,
which modifies account limits for all students enrolled in a
course.
- Class Lists: Is still being used by C&CI to generate class lists by
request of the Instructor. Bill Shirey is writing a replacement for
this scheduled to be in production for the start of Fall quarter.
We plan to keep running this old Austen-based process for Summer
quarter which will end Aug 20 then switch customers to Bill Shirey's
new replacement.
- ADD: Makes the CPF and CDF files which are used to modify account limits,
like disk quotas, for all the student accounts enrolled in a class.
This uses the EDF file to pick out all the students enrolled in a
class, and create two files which are ftp-ed to the galaxy desired
to modify account limits. Ken has a nightly process that reacts to
the presence of these files and does the modifying. When the files
are no longer present, the account limits revert back to the default
level. I suspect EOQ gets rid of the files at the end of the
quarter. This functionality is not yet addressed in any
replacement, so still needs to be assigned.
- Dave Wall: Dave occasionally uses Austen only to receive ftp-ed
data (from the A-series) which he uses to maintain the Faculty
Senate listproc addresses. He can simply receive this ftp-ed data
elsewhere and does not need Austen.
- Other uses of Austen: I know of a few folks still using Austen unrelated
to accounting. I believe I have been in some form of contact with all of
them, and have a "call list" to contact before Austen is finally shut
down. Everyone is aware of Austen's imminent demise, although there is
varying understandings of the schedule.
Date: Fri, 16 Apr 1999 15:12:14 -0700 (PDT)
From: Hugh Sheets
To: hornung@u.washington.edu, hugh@cac.washington.edu, ken@cac.washington.edu,
pete@cac.washington.edu, remmers@cac.washington.edu,
stenvik@cac.washington.edu
Cc: deroest@cac.washington.edu, drr@cac.washington.edu
Subject: Highlights of 99/04/15 Accounting meeting....
From 99/04/15 meeting:
This meeting directed focus to the task of getting AST off Austen. We
have advertised that Austen is to be decommissioned July 1, 1999, which
is 2.5 months from today. Since we (the AST group) should take the
"lead by example" leadership role, we will strive to be off Austen as we
expect others to be.
There is still a "lot of stuff" running on Austen (Hugh browsed around
on Austen noting file update dates). This does not mean it has not be
replaced by processes running elsewhere, but now is the time to examine
these Austen processes carefully to be sure *all* the functionality has
been replaced, it has been dumped in the streamlining process, or if it
still needs to be attended to do so. When possible, we can shut off the
Austen processes as we work through them.
The goal of this meeting was to designate a reconnaissance team to
survey what is still happening on Austen, and report back next week.
Hopefully a more directed to-do list will then be established.
Hugh drew three general categories of Austen processes that seem to
cover what AST is concerned with:
- Administrative - authorization handling including Student, Fac/Staff,
AVF, registration (EDF), class lists, expiration, etc. Tom has already
done significant work in this category, so he will look over this area.
- Billing - the suite of programs run and data used to generate monthly
invoices and CTIs. Hugh will look at this.
- User - such programs as CHARGES that can be run to generate details
on monthly billing. Tracy will look at this.
Mike Hornung will alert the C&CI staff to note what they do if anybody
logs in to Austen to perform any tasks to be sure we don't overlook
anything.
Hugh drew a time line denoting scheduled events between now and July
1. As the normally scheduled processes come along, we hope to be
running them in production on daffy, the new billing machine, possibly
in parallel to Austen as a backup.
Date: Thu, 10 Dec 1998 15:22:29 -0800 (PST)
From: Hugh Sheets
To: Internal Accounting Group , fox@cac.washington.edu,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Cc: deroest@cac.washington.edu
Subject: Highlights of 98/12/10 Accounting meeting....
From 98/12/10 meeting:
Hugh, Ken, Tom, and Tracy met to talk about billing.
Tom has come up with a quite revolutionary plan (compared to the old system
on Austen) to implement billing. All usage data (CUFs) are being processed
on vitcos, and the data is stored in tables in the database rather than
flat files. Everything that accesses the data, including "POSTing" type
operations to inject billing records, will be done via ACCESS on Windows
machines. ACCESS will be used to generate reports, including CTIs and
invoices. Operations such as running monthly billing will run in real time
on data stored in Shuksan. We have to be sure to store data down to the
level needed for "CHARGES" detailed reporting.
ACCESS is a very easy tool to use to produce reports (including CTIs and
invoices) from data stored in databases, on-the-fly. It is very easy to
modify or produce custom reports. Rates will be stored in Shuksan, so it
would be easy to apply new rates without rebuilding a suite of programs.
Anyone needing access to Shuksan data, such as whoever runs billing, will
need a Windows machine.
Tom will ask Oren, Doris, Jeanne if this will be a problem - we don't think
so. Tom will also work on creating the ACCESS clients to run the standard
monthly billing. We need to be sure we implement the necessary security to
allow only the authorized people to access Shuksan via ACCESS - some to
read only, a select few to make changes like post charges, change rates,
etc. A SecurID gateway betwen ACCESS and Shuksan would be ideal.
Date: Fri, 16 Oct 1998 11:01:28 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group , fox@cac.washington.edu,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Subject: Highlights of 98/10/15 Accounting meeting....
From 98/10/15 meeting:
Hugh, Ken, Tom, and Tracy met to talk about billing - a term we are using
to encompass the processes currently run on Austen to produce invoices and
CTIs, reports, and also production processes such as class lists which are
not really billing. The goal is to get all the remaining production
processing off Austen and onto a UNIX host(s).
Our plan is to have a host as the data repository, and another host(s) as
the "billing machine". Our data host, already well underway is the Shuksan
database on vitcos. Where Shuksan resides is not really important, and
this can very well (and easily) change. We are planning on making daffy
the "billing machine", where the various clients will be run for
billing/reporting. The billing machine can also easily change.
At this point, a number of foundation pieces are already functioning in
Shuksan. All the authorization data, and also the basic building block of
billing, the CUFs, are being shipped to, received, and processed daily in
Shuksan in parallel with production processing still happening on Austen.
The CUFs, Computer Usage Files, are files produced daily on each galaxy by
the "watcher". The CUFs can be used as-is as building blocks for billing.
The necessary programs from the CUF on up can be ported from Austen to the
billing machine (UNIX) and updated/streamlined/enhanced as needed.
From lessons too often relearned, portability is critical, so a tulsafied
source tree is planned, minus vendor/platform specifics exemplified by the
recent zorra-to-zorra2 painful migration.
In the first phase of billing, Tom will continue to replicate the daily
"uaday" functionality on Austen in Shuksan on the data repository machine.
Others can work on porting the billing programs and procedures in the next
phase. This is easy to say, but in reality we are talking about literally
hundreds of programs/procedures on Austen, and a lengthy list of
changes/enhancements accumulated over time to be factored in. We want to
automate more to reduce human interaction, and make web-based clients where
clients are needed.
Date: Fri, 28 Aug 1998 14:03:13 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group , fox@cac.washington.edu,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Subject: Highlights of 98/08/27 Accounting meeting.....
From 98/08/27 meeting:
- Tom set up the first affiliate UWnetID, "jherman" for WWAMI/b3. He
just set up the kerberos principal by hand and has not yet added
the supporting authorization information to Shuksan.
- Pete implemented the initial version of web new accman as scheduled
on Aug 20. This essentially just reports on what accounts one has
currently set up. He is working on the addition of new web.
- Tom has set up a new AIX box called sahale1, which is intended to
be one of the replicated homes of Shuksan. He is investigating
Informix or DB2 as the database engine.
- Last week Tom distributed an LDAP authorization service announcement
to people/groups in C&C known to be interested in LDAP queries to
our authorization server. It points out some "how-to-do-it" web
pages (start at http://staff.washington.edu/remmers/ldap/) and offers
a forum for discussion and development, which no one has responded to
yet.
- A discussion ensued, with no clear end, about whether we should
promote LDAP protocol only as the way to access our authorization
data, or to *also* promote a mango API. We have talked about both
for some time now, but there has been some recent opinions put forth
that we should not "advertise" the mango API outside UCS due to the
difficulty in supporting it over the long term. If I can state a
personal opinion, I think we could offer both and let customers decide
themselves. There is no guarantee of LDAP's longevity or stability
over the same for a locally developed mango API.
- Next (or soon) meeting will be dedicated to discussing getting the
remaining Austen processes off Austen, the traditional accounting/
billing/reporting. Unless specifically defined, we are not planning
on providing any reports, only data for custom reporting as needed
to who needs it.
Date: Fri, 10 Jul 1998 12:49:55 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Subject: Highlights of July 9, 1998 Accounting Meeting....
From 98/07/09 meeting:
Newsy updates:
- Pete has added Ken's longer password fix to web renew
- Pete is toiling away on web new - cleaning up some parts that he
considered not optimal. The "accman" enhancements are still being
defined so he is working on a basic foundation while awaiting specific
direction.
- AVF: Zephyr called attention to the cumbersome current billing process
for supplemental accounts. The billing, for example for email
accounts, is maintained in a separate file that must be editted by
hand to remove a billing record when an account expires. If this
step is not done, billing continues for an expired account. We noted
this problem and assure a better system linked automatically.
- C&CI predicted potential problems with requiring a "sponsor" to own
supplemental accounts in every case except medical residents and
extension students. We stuck to this requirement, since we could
at least always identify a Department Chair for a sponsor. If the
Department Chair does not want to sponsor a supplemental, we
probably should not be setting one up. Tom mentioned we can phase
this in by first requiring all new supplementals to conform, then
working up some plan to retroactively fix up existing supplementals.
- Xerox printing, particularly invoices: Jim will look at the file
format Hugh sent. We are awaiting special form samples from Jeanne,
and window envelopes, etc. to see if these can be sent to another
Xerox as-is, or if they can be converted to print on other printers,
perhaps as PostScript format. When billing pieces that *must* be
printed are rewritten (to get off Austen) we will not build in
manufacturer specific "features" that require a specific printer.
- Mike pointed out "whatami" on saul does not identify a category 7
user. "whatami" is used currently to determine if a user is student,
staff, or faculty for purposes of setting up the proper web server
account by using the account category. This process is not used for
the new web servers so this problem will go away. Apparently, some
C&CI folks use "whatami" as a tool for determining user category.
- Tom has decided to use a UNIX LDAP server rather than an NT platform
at this time for security reasons.
Tom is meeting today with Jean Wells to discuss authorization needs
for the USER project. Our part of this is to store data provided by
others (IS, departments, etc.) so a data structure needs to be designed
so LDAP queries can return what is needed.
We are planning on using LDAP groups to provide authorization on
who is authorized to view/change/add authorization information. For
example, a UW class will have a group defined for the students in the
class, this information we get from the SVF. There will be a related
group for the class instructor, who can then add others to this related
group such as TAs who can be authorized to access the class group.
Date: Thu, 25 Jun 1998 13:47:16 -0700 (PDT)
From: Thomas W Remmers
To: New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers , stenvik@u.washington.edu,
Yonah Karp
Subject: backup
Liz informed me they dump all the databases at 10 PM every night and
keep a running transaction log throughout the day, so it is possible to
rebuild a database to the exact point of a hardware failure.
If the database gets corrupted, they could perform this procedure for
our database space and restore a database in about one hour. Doing so
would delete and restore all databases in our database space.
The reason I didn't create backups was that I knew this in the back of
my mind, Liz explained this to me 6 months ago.
We could keep our own dumps of the database if we needed to restore more
quickly or we could not contact someone to do the above procedure. We
wouldn't get the transaction log so the database would be restored to
the state at the dump time, a disadvantage.
I'll put together an emergency restore procedure, but I think it should
only be used in absolute emergencies. If we did lose our data it most
likely will be a system problem, in which case everyone's databases will
need to be restored and Ping and Liz will restore everything.
Tom
Date: Thu, 18 Jun 1998 19:11:58 -0700 (PDT)
From: Thomas W Remmers
To: New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers , stenvik@u.washington.edu,
Yonah Karp
Cc: dorish@u.washington.edu, "Michael S. Hornung"
Subject: Re: student and staffdir (fwd)
---------- Forwarded message ----------
Date: Wed, 13 May 98 11:29:47 -0700
From: Ken Lowe
To: remmers@u.washington.edu
Cc: donn@cac.washington.edu, hugh@cac.washington.edu
Subject: Re: student and staffdir
Expiration runs on horton on a regular basis. I don't know what
Erin's plans are.
--------
Actually I'm not sending the cufexp.dat file to horton at this time but
I should. It brings up the question on how to keep system accounts from
expiring on the news galaxy. There are two possibilities:
1) Add an entry to the AVF
2) Set the category to 6
In method 2 I think the master source for the category is cdf.dat. For
supplemental accounts the method of assigning a category eludes me from
empirical evidence.
I'd like to redo how we prevent system accounts from expiring, hopefully
to avoid needing to add an AVF entry. We should talk about this at one
of our next meetings.
Tom
Date: Tue, 16 Jun 1998 12:55:17 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu
Subject: Highlights of 98/06/11 Accounting meeting....
From 98/06/11 meeting:
Tom has been attending a MicroSoft technical conference; this plus what
we have gleaned from the recent ;login article about kerberos
authentication in NT 5 indicates we will need to support a MicroSoft
family of products. If not used exclusively as our kerberos server,
then in parallel with it. Our minds must remain open to using NT 5 in
place of UNIX.
We must remember to review data stored on Austen and stop maintaining
what is not needed.
The Sequim backup fails every night as something is accessing it. Tom
is reviewing backup of the databases to be sure we are protected.
Some discussion on supplemental accounts. Currently there are fourteen
account type codes recognized. We keep only one owner per account, and
it was decided to only keep the current owner - we will not maintain
previous owners. We will keep a list of additional users of a
supplemental account, who will also be authorized for password changes.
We want to make available code samples of how developers would do
authentication and authorization. It was mentioned Jim Fox has some
that we could make available on the web page.
Tracy/Tom have made extensive additions to data in Shuksan, actually in
the test database Sequim. Sequim now contains all the Li information.
The mango server queries Sequim, and Tracy has a modified wu library in
sy99 that interfaces to Sequim. When enhancements and testing are
completed, we can switch over to using Sequim, which will be Shuksan by
then. All applications that use the wu library need to be rebuilt. The
actual switchover will need to be carefully choreographed, and it is not
clear what Li would do. Perhaps still do email forwarding, maybe remove
it completely. Some stress testing of Sequim will be needed to
determine if it could serve email forwarding fast enough to replace Li.
Some more work involved here, but a lot of progress has been made.
Sequim now contains lots of information, and utilities like "who" need
to be evaluated to see if everything needs to be returned, and in what
format, as the volume of information can be prohibitive. Mike Hornung
will take a look at this.
Web New is being tested and refined. A demo will be given in the
FSCO-AST meeting this afternoon.
Future meeting topic: Close look at how authorization will/might work.
Where will authorization information reside, how might applications get
it, how do we get the information. Class lists included.
Task review:
------------
Tom: Review vitcos Shuksan and Sequim backups - usual backups often fail.
Sequim (Shuksan) development.
Tracy: Sequim (Shuksan) development.
Fox: Authentication, authorization code samples for application developers
Mike: Look at volume of information in Sequim - what to display where.
Date: Fri, 29 May 1998 09:14:54 -0700 (PDT)
From: Oren Sreebny
To: Doris Gallaugher
Cc: Thomas W Remmers ,
Sandra Moy ,
Jim DeRoest ,
New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" , stenvik@u.washington.edu,
Michael Hornung ,
Yonah Karp
Subject: Re: Supplemental Accounts
Agreed.
Date: Fri, 29 May 1998 07:30:46 -0700 (PDT)
From: Doris Gallaugher
To: Oren Sreebny
Cc: Thomas W Remmers ,
Sandra Moy ,
Jim DeRoest ,
New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" , stenvik@u.washington.edu,
Michael Hornung ,
Yonah Karp
Subject: Re: Supplemental Accounts
Oren,
I agree with all but the idea of requiring a sponsor for Extension
students. These students pay a tech fee in order to be eligible for the
same privileges as regular UW students. They're omitted from the svf for
technical reasons, rather than political ones. And *many* of them jump in
and out of the svf quarter by quarter depending on registration method.
The idea of changing the owner back and forth... yuk. If only Extension
registration info could be somehow dumped to the svf/avf.
Thanks,
Doris
Date: Fri, 29 May 1998 06:37:18 -0700 (PDT)
From: Oren Sreebny
To: Thomas W Remmers
Cc: Sandra Moy ,
Jim DeRoest ,
New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" , stenvik@u.washington.edu,
Yonah Karp , dorish@u.washington.edu
Subject: Re: Supplemental Accounts
Tom and all -
I think this is starting to look very good from my point of view - nice
work! Some specific comments below marked with ***
- Oren
On Fri, 22 May 1998, Thomas W Remmers wrote:
> AVF and supplemental account technical and policy issues with regard to
> the new accounting system were discussed at length yesterday with a good
> deal of consensus. The summary is at
> http://neruda.cac.washington.edu/ast/projects/acctg/avf.html.
>
> The basic premise was that all supplemental accounts would be owned by a
> current UW employee (in HEPPS). Supplemental accounts include
> department, course, email list and sponsored accounts. Only medical
> residents and extension students would not need an employee sponsor.
*** I wonder whether even these account types should have a sponsor - we
need in all cases I think for someone to accept the responsibility for
ensuring proper use of an account within the rules, and by allowing
accounts to not have a sponsor we are implying that C&C is accepting that
responsibility, which I don't think we want. So we should, I think, get
someone at Extension to agree to be listed as the sponsor for Extension
student accounts and for the someone in each of the departments with
residents to accept the responsibility for the resident accounts (if we
don't phase those out altogether this summer).
>
> A serious question did arise after the meeting about what information we
> would store about a supplemental account. If the plan is to allow
> employees to create up to 4 supplemental accounts with new or web new
> (as we heard in the meeting), then there is no way to validate
> information about the account or its intended purpose (name, ssn etc.).
> In that case, is there any reason to store more than the most basic
> information, e.g. whether the account is a deparmental, course,
> sponsored etc.?
>
> It seems there may be an issue with the usage policy that an account
> cannot be shared. What would keep an employee from creating a
> supplemental sponsored account for a friend and saying it was
> legitimate? We have no way of knowing. One possibility is to require
> all sponsored supplemental accounts to go through C&CI then trusting
> employees to not hand out supplemental accounts for non-UW people, but
> it seems a stretch to enforce that.
We may indeed get to a point where staff and faculty can create their own
supplemental accounts (up to some limit) for purposes such as course
accounts, departmental accounts, etc. I think that there's no real way to
validate their intent, but we need to have that creation process be
explicit in getting them to at least state what the purpose of the account
is and to tell them that they're accepting the responsibility for proper
use of the account. From that point on, abuse or misuse are management
issues which can be dealt with as they arise.
Sponsored accounts are, I think, a different thing. The intent here is
for departments to be able to say "We are treating this outside person as
a member of our department for some set of business reasons, and we are
prepared to justify that if need be" and because they pay for these
accounts, we should (at least for the forseeable future) require C&CI
intervention for these accounts.
>
> The one saving factor is that all supplemental accounts will be owned by
> a current employee, so there will always be an accountable person at the
> UW.
>
> This is long winded, but to summarize what I think we need from the
> directors,
>
> 1. Evaluate the consensus summary on the Web page.
>
> 2. Is the intention to let a certain group (current employees?) create
> their own supplemental accounts?
>
> 3. What information do we need about a supplemental account?
>
> 4. Do we place contraints, hurdles or limitations on the kind of
> supplemental accounts that can be owned?
>
> 5. Do we attempt to treat sponsored accounts differently?
>
> As well, if anyone at the meeting has comments about the web page, let
> me know.
>
> Thanks,
>
> Tom
>
Date: Fri, 22 May 1998 14:14:40 -0700 (PDT)
From: Thomas W Remmers
To: Sandra Moy , oren@cac.washington.edu,
Jim DeRoest
Cc: New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers , stenvik@u.washington.edu,
Yonah Karp , dorish@u.washington.edu
Subject: Supplemental Accounts
AVF and supplemental account technical and policy issues with regard to
the new accounting system were discussed at length yesterday with a good
deal of consensus. The summary is at
http://neruda.cac.washington.edu/ast/projects/acctg/avf.html.
The basic premise was that all supplemental accounts would be owned by a
current UW employee (in HEPPS). Supplemental accounts include
department, course, email list and sponsored accounts. Only medical
residents and extension students would not need an employee sponsor.
A serious question did arise after the meeting about what information we
would store about a supplemental account. If the plan is to allow
employees to create up to 4 supplemental accounts with new or web new
(as we heard in the meeting), then there is no way to validate
information about the account or its intended purpose (name, ssn etc.).
In that case, is there any reason to store more than the most basic
information, e.g. whether the account is a deparmental, course,
sponsored etc.?
It seems there may be an issue with the usage policy that an account
cannot be shared. What would keep an employee from creating a
supplemental sponsored account for a friend and saying it was
legitimate? We have no way of knowing. One possibility is to require
all sponsored supplemental accounts to go through C&CI then trusting
employees to not hand out supplemental accounts for non-UW people, but
it seems a stretch to enforce that.
The one saving factor is that all supplemental accounts will be owned by
a current employee, so there will always be an accountable person at the
UW.
This is long winded, but to summarize what I think we need from the
directors,
1. Evaluate the consensus summary on the Web page.
2. Is the intention to let a certain group (current employees?) create
their own supplemental accounts?
3. What information do we need about a supplemental account?
4. Do we place contraints, hurdles or limitations on the kind of
supplemental accounts that can be owned?
5. Do we attempt to treat sponsored accounts differently?
As well, if anyone at the meeting has comments about the web page, let
me know.
Thanks,
Tom
Date: Fri, 22 May 1998 15:04:48 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu,
yonah@cac.washington.edu
Cc: deroest@cac.washington.edu, dorish@cac.washington.edu,
zephyrmc@cac.washington.edu
Subject: Highlights of 98/05/21 Accounting meeting....
From 98/05/21 meeting:
Jim DeRoest, Doris, and Zephyr joined us for the meeting.
Tracy has his new mango server running on "mango.u.washington.edu",
which translates to a couple of redundant machines, same as li right
now, Cybele and Horton. They are monitored by Argus. The web who and
validate are now using this new server. Tracy says the search by name
takes a while now as the name is not an indexed field in Shuksan, but
Tom will change this. Also, since Shuksan does not yet contain all the
information Austen had, it cannot return as much as the Austen mango
did. This is a short term situation. Tracy has an API which he is
using for web who and validate, and he is expanding the API to include
li calls. The AVF web client is also soon to use mango.
Ken is planning to remove shadow passwd files and wondered which
machines to do first. After discussion, we thought all beckers and
homers. (Later in the FSCO-AST meeting, Oren said becker1-2, and
dante10-19, and next Wednesday is fine. We had the word previously that
CS didn't like just doing some machines in a cluster as it was difficult
to debug if problems arose, but they changed their minds.)
The rest of the meeting was spent in discussion of a portion of the
layout of Shuksan concerning owners and accounts, particularly how to
handle AVF-type supplemental accounts/owners. Tom had provided a plan
prior to the meeting which he will modify and redistribute. He wants to
work hard on getting owners for all current AVF accounts (there are
maybe 1000 with no known owners) so he can move the current AVF
information into the new layout. Zephyr pointed out a file on daffy
that may provide owners for some if not all the AVF accounts without
owners.
Task review:
------------
Tom: Work on adding levels of authorization in Shuksan.
Make name field in Shuksan indexed.
Update AVF policy/plan, implement
Tracy: Work on programming interface calls to mango.
Date: Fri, 22 May 1998 14:14:40 -0700 (PDT)
From: Thomas W Remmers
To: Sandra Moy , oren@cac.washington.edu,
Jim DeRoest
Cc: New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers , stenvik@u.washington.edu,
Yonah Karp , dorish@u.washington.edu
Subject: Supplemental Accounts
AVF and supplemental account technical and policy issues with regard to
the new accounting system were discussed at length yesterday with a good
deal of consensus. The summary is at
http://neruda.cac.washington.edu/ast/projects/acctg/avf.html.
The basic premise was that all supplemental accounts would be owned by a
current UW employee (in HEPPS). Supplemental accounts include
department, course, email list and sponsored accounts. Only medical
residents and extension students would not need an employee sponsor.
A serious question did arise after the meeting about what information we
would store about a supplemental account. If the plan is to allow
employees to create up to 4 supplemental accounts with new or web new
(as we heard in the meeting), then there is no way to validate
information about the account or its intended purpose (name, ssn etc.).
In that case, is there any reason to store more than the most basic
information, e.g. whether the account is a deparmental, course,
sponsored etc.?
It seems there may be an issue with the usage policy that an account
cannot be shared. What would keep an employee from creating a
supplemental sponsored account for a friend and saying it was
legitimate? We have no way of knowing. One possibility is to require
all sponsored supplemental accounts to go through C&CI then trusting
employees to not hand out supplemental accounts for non-UW people, but
it seems a stretch to enforce that.
The one saving factor is that all supplemental accounts will be owned by
a current employee, so there will always be an accountable person at the
UW.
This is long winded, but to summarize what I think we need from the
directors,
1. Evaluate the consensus summary on the Web page.
2. Is the intention to let a certain group (current employees?) create
their own supplemental accounts?
3. What information do we need about a supplemental account?
4. Do we place contraints, hurdles or limitations on the kind of
supplemental accounts that can be owned?
5. Do we attempt to treat sponsored accounts differently?
As well, if anyone at the meeting has comments about the web page, let
me know.
Thanks,
Tom
Date: Wed, 20 May 1998 13:58:58 -0700 (PDT)
From: Tracy Stenvik
To: Doris Gallaugher
Cc: hugh@u.washington.edu, remmers@u.washington.edu
Subject: new server for who/validate
I've just switched you guys to the new mango server for all who and/or
validate requests. This server talks directly to shuksan, so the data
should be as up to date as possible, and is (thank god, eh?) off of austen
for good.
You should see little user-visible changes, except for the name search in
who, which now only searches by last name. I don't know of how much value
a search by name is to you, but as this field is not keyed in shuksan the
search can take a long time to return so don't rely on it too heavily.
As for who, I've given you control of the file which permits access to
the various types of data (avf/fvf/svf) a user may view. Instead of the
three discreet files (mda.dat, mdf.dat, mds.dat) users are placed in one
file now with a 'privilege mask'. This file is in ~info/data/who.dat.
Here's what it looks like currently,
daffy2% cat ~info/data/who.dat
7 info
7 adminapp
7 imf
7 remmers
7 hugh
7 fox
7 sys
7 oren
7 mel
7 jbranom
7 training
3 pur7015
3 hbsmith
Setting the 'privilege mask' is constructed as follows: Determine which
'bits' are appropriate for the user in question, add the 'bits' up, and
enter into the file along with the logon id.
The bits are as follows:
Bit Meaning
--- -------
1 user may see avf records
2 user may see fvf records
4 user may see svf records
So, taking 'info' as an example, you want to see all data types, so your
mask is (1 + 2 + 4 = 7). 'hbsmith' can't see svf records, so his mask is
(1 + 2 = 3).
I'll switch over the avf web-page stuff to use mango as well within a day
or two.
I wasn't sure who else to share this information with, so I'll leave it up
to you.
---
Tracy Stenvik
University Computing Services 354843. University of Washington
email: imf@u.washington.edu voice: (206) 685-3344
Date: Mon, 18 May 1998 15:08:57 -0700 (PDT)
From: Thomas W Remmers
To: New Accounting System Development -- Jim Fox ,
Hugh Sheets , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers , stenvik@u.washington.edu,
Yonah Karp
Subject: AVF Policy
I would like to finalize what we think the AVF should do at our next
meeting (this Thursday). Then I'd like to take these recommendations to
Oren, Sandy and Jim and have them approve them. I see the AVF policy as
a top priority in keeping the project moving along. Down below are some
ideas for the AVF policy. If you're interested you could look them over
before the meeting.
I want split up the AVF into it's two primary types.
A. Records that keep existing accounts from expiring when the
person leaves the University. This type of record refers to
a person, call these AVF Owner records.
B. Supplemental, departmental, course etc. records that reflect
a secondary computer account. This type of record refers
not to a person so much as to a computer account, call these
AVF Account records.
The first type actually has a subset,
A1. Sponsored people who were never at the UW but for whatever
reason have a UA account. The AVF record will prevent this
account from expiring.
The AVF table has been moved to Shuksan and C&CI maintains it via a Web
page on Daffy2. I have already made these changes to the AVF records
and to the interface.
1. An owner field is required, which may be an encrypted ssn or
student number. Currently no check is made on the value of this
field.
2. An account type field is required, which will is useful for
AVF records of type 2, supplemental accounts. These types
currently are, and will be used to determine which Web server
an account will move to from Weber,
1 Faculty
2 Staff
3 Department
4 Course
5 Student
9 Other
Changes in Policy
-----------------
I recommend these changes in policy, or policy ideas that need
discussion or decision,
- Every AVF Owner record should have an owner field that is an
encrypted SSN or student number. It is not necessary this
value be currently in HEPPS or SDB, in fact it most likely will
not be.
- Every AVF Owner record that is used to prevent expiration of an
account must have a future expiration date to prevent that person
from keeping an account forever. The expiration date can be
extended, but possibly for only X period of time, say one quarter
or one year.
- Likewise every AVF account record should have an expiration date so
that supplemental accounts can disappear even if the owner is still
at the UW.
- All supplemental accounts must have an owner who is currently in
HEPPS or the SDB, or must be owned by a designated department in
some way, e.g. the Chemistry Department, which will always exist.
If the owner leaves the UW, the supplemental account(s) will expire
in the same manner regular accounts expire.
- A sponsored AVF Owner record must include, in the comments or
a new field, the encrypted ssn or student number of a current
owner
or
- A sponsored account is really a type of supplemental account for
an existing owner. If some VIP needs an account, someone at the
UW will actually "own" the account. If the sponsor leaves, the
sponsored account will be deleted.
- Students will not be allowed to own supplemental accounts.
- Email warnings will be sent the maximum of 30 days or as soon as
can be determined to all accounts that expire because of the AVF.
Date: Mon, 11 May 1998 15:57:13 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu,
yonah@cac.washington.edu
Cc: deroest@cac.washington.edu, jblank@cac.washington.edu
Subject: Highlights of 98/05/07 Accounting meeting....
From 98/05/07 meeting:
Jim DeRoest and Jim Blankenship joined us for the meeting.
Jim D. talked about a meeting he had attended with the My UW folks. The
My UW developers are interested in what they call a "back end bus", or
middleware they can query in a variety of protocols, which will decide
what data source needs to be queried to fulfill the request, make the
secondary queries in the appropriate manner, then bundle up all the
secondary responses as a response to the initial query.
Benefits of this model include insulation between end applications and
databases which can change. As long as the middleware is updated, the
applications don't have to. Persistent connections between the
middleware and databases can vastly increase performance. Security is
improved by not exposing all the "back room databases" to user queries.
This is essentially the technology Tracy and Tom are developing with the
mango server interface to Shuksan. Tracy is working on a set of
interface calls to mango now. This technology can be used for other
servers talking to other databases in a similar manner, so is a big step
towards this proposed middleware, and will head off proliferation of
parallel development for similar uses by many developers. Jim
Blankenship is interested in using this technology both for My UW and
the USER project. He will keep in touch with Tracy and Tom for access
to the interface calls.
One issue we have discussed before is authorization - who can make
queries and/or make changes to databases (Shuksan) via mango? We need
to revisit levels of authorization we once proposed for Shuksan, and we
should proceed even though we have no good idea how we will actually get
this data. We could at least add it "by hand" for select individuals as
needed for now. One relationship looming is the instructor/class/class
member relationship.
Task review:
------------
Tom: Work on adding levels of authorization in Shuksan.
Tracy: Work on mango server to interface to Shuksan..
Work on programming interface calls to mango.
Date: Tue, 28 Apr 1998 14:10:02 -0700 (PDT)
From: "Michael S. Hornung"
To: Hugh Sheets
Cc: Internal Accounting Group ,
hugh@cac.washington.edu, ken@cac.washington.edu,
pete@cac.washington.edu, remmers@cac.washington.edu,
stenvik@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: avf
All the AVF accounts that aren't category 7 should be easy since the
category tells us which web server they ought to be on. Can't the owner
be grabbed from Li somehow (assuming there is one, but it's not in the
AVF yet)?
The other 2800 or so category 7 accounts are going to be a problem. Their
owners (if they have one) could be snatched from Li as well, but we have
no way of telling which web server they want the account to be available
on. I suppose a bulk emailing could do the job, even though it would be a
swamp.
_________________________
Michael Hornung, hornung@u.washington.edu
Student Staff, Computing & Communications Information
(206) 543-5970, FAX: (206) 543-3909, Box 355670
On Tue, 28 Apr 1998, Hugh Sheets wrote:
>Tom: Great! This takes care of all new supplementals created. Now,
> we need some method of categorizing exiting accounts. Mike, any
> ideas? Maybe a bulk emailing to the existing supplementals?
>
> We also need this catagory in the LDAP server, so anyone who
> needs to know this usage category, like newweb, can query for it.
>
>Hugh
>
>On Fri, 24 Apr 1998, Thomas W Remmers wrote:
>
>> I sent this to Mike and C&CI
>>
>> Tom
>>
>>
>> -------
>>
>> Mike et. al.
>>
>>
>> I've changed the avf programs and html stuff to include owner and
>> account type. The only thing that doesn't work is the batch add, which
>> I disabled in avfadd.html and you should fix. The previous files are in
>> the old directory. The new fields should be intuitive:
>>
>> - Owner (Encrypted SSN or Student #): This is the same field that is
>> input with the addid program.
>>
>> - Account Type (primary use): This field is used to identify the
>> purpose of the account, which will be used to determine which web
>> server the account can use. The choices are
>>
>> 1 Faculty
>> 2 Staff
>> 3 Department
>> 4 Course
>> 5 Student
>>
>> and should be self-evident for a particular entry.
>>
>> Thanks,
>>
>> Tom
>>
>
Date: Tue, 28 Apr 1998 12:14:44 -0700 (PDT)
From: Thomas W Remmers
To: Hugh Sheets
Cc: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
stenvik@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: avf
> We also need this catagory in the LDAP server, so anyone who
> needs to know this usage category, like newweb, can query for it.
Newweb et. al. should contact mango, not LDAP.
Tom
Date: Tue, 28 Apr 1998 10:17:23 -0700 (PDT)
From: Hugh Sheets
To: Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
remmers@cac.washington.edu, stenvik@cac.washington.edu,
yonah@cac.washington.edu
Subject: Re: avf
Tom: Great! This takes care of all new supplementals created. Now,
we need some method of categorizing exiting accounts. Mike, any
ideas? Maybe a bulk emailing to the existing supplementals?
We also need this catagory in the LDAP server, so anyone who
needs to know this usage category, like newweb, can query for it.
Hugh
On Fri, 24 Apr 1998, Thomas W Remmers wrote:
> I sent this to Mike and C&CI
>
> Tom
>
>
> -------
>
> Mike et. al.
>
> I've changed the avf programs and html stuff to include owner and
> account type. The only thing that doesn't work is the batch add, which
> I disabled in avfadd.html and you should fix. The previous files are in
> the old directory. The new fields should be intuitive:
>
> - Owner (Encrypted SSN or Student #): This is the same field that is
> input with the addid program.
>
> - Account Type (primary use): This field is used to identify the
> purpose of the account, which will be used to determine which web
> server the account can use. The choices are
>
> 1 Faculty
> 2 Staff
> 3 Department
> 4 Course
> 5 Student
>
> and should be self-evident for a particular entry.
>
> Thanks,
>
> Tom
>
>
Date: Fri, 24 Apr 1998 15:18:03 -0700 (PDT)
From: Thomas W Remmers
To: Jim Fox
Cc: Hugh Sheets ,
Internal Accounting Group ,
hornung@u.washington.edu, hugh@cac.washington.edu,
ken@cac.washington.edu, pete@cac.washington.edu,
stenvik@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: 98/04/23 Accounting meeting highlights....
The numbers are, from the new AVF Web page,