From bmurray at snf.stanford.edu  Sun Dec  2 01:31:56 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sun, 2 Dec 2001 01:31:56 -0800 (PST)
Subject: Success
Message-ID: <Pine.LNX.4.04.10112020130260.32103-100000@snf.stanford.edu>

John,

I killed the staff manager on rosen this morning, and all servers were
restarted automatically after the admin manager detected the crash.

Bill



From shott at snf.stanford.edu  Mon Dec  3 14:42:06 2001
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 03 Dec 2001 14:42:06 -0800
Subject: Wish list ...
Message-ID: <3C0BFFBE.3FCD18F@snf.stanford.edu>

Bill and Mike:

Here is my very preliminary list of new and improved things for Coral.  At
this point, it is mostly "stream of consciousness" rather than a well thought
out list ...

Big Projects:

Inventory server and client

More configuration stuff in the database instead of in the code or Makefiles.
(This probably includes a configuration client (the equivalent of
"preferences") ...

Process server and client (even a barebones system is a big project) ...

New maintenance client

Medium Projects:

Autoconf or some other means of more automatically configuring and installing
Coral software.

Support for Postgres database

Set up Admin group stuff so that only members of the admin group can edit
other people's info .... also, make sure that non-admin folks can't even pull
up the edit window for anyone but themselves.

Data validation for resource client ... (including, I hope, storing those
rules in the database).

Small Projects:

Modify accounting script to account for labtime.

Menu items for charging lab time to "non-default" projects (probably 2 menu
items ... one for changing the project effective the start of this login and
one for changing it "now").

Call "newuser", "mailforward", and "setpasswd" from resource client.

I'm sure that I'm forgetting some things, but, hopefully, this is a start ....

Thanks,

John


From bmurray at snf.stanford.edu  Wed Dec  5 17:44:14 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 5 Dec 2001 17:44:14 -0800 (PST)
Subject: about wbgaascl
In-Reply-To: <3C0ECACB.721CCE3F@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10112051740470.10224-100000@snf.stanford.edu>

Uli,

Once the maintenance guys get separate Walker boxes installed, I would
be happy to update the database to make this change.  Len can provide
me with the card number and channel of the two boxes.

Bill

PS John, I assume you have no objection?

On Wed, 5 Dec 2001, Uli Thumser wrote:

> 
> 
> -------- Original Message --------
> Subject: about wbgaascl
> Date: Wed, 21 Nov 2001 14:24:51 -0800
> From: Uli Thumser <uli at snf.stanford.edu>
> Reply-To: uli at snf.stanford.edu
> Organization: SNF
> To: computer at snf.stanford.edu
> 
> Is it possible to change wbgaascl into two units on Coral?
> wbgaas-hpr
> wbgaas-hpl
> 
> Uli
> --
> Uli Thumser
> Stanford Nanofabrication Facility
> Center for Integrated Systems
> 420 Via Palou Mall, CIS Room 146
> Stanford, CA  94305
> (650)725-3694
> uli at snf.stanford.edu
> 



From shott at snf.stanford.edu  Wed Dec  5 18:08:36 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 05 Dec 2001 18:08:36 -0800
Subject: about wbgaascl
References: <Pine.LNX.4.04.10112051740470.10224-100000@snf.stanford.edu>
Message-ID: <3C0ED324.50EB32BD@snf.stanford.edu>

Bill et al:

No, it is fine with me if wbgaascl becomes 2 machines ...

John


From shott at snf.stanford.edu  Wed Dec  5 23:21:08 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 05 Dec 2001 23:21:08 -0800
Subject: Resource client bug and possible questionable behavior?
Message-ID: <3C0F1C64.957D4153@snf.stanford.edu>

Bill and Mike:

I did a bit of work with the resource client and noticed a couple of things:

1. The window that is used for the "Replace Project", "Replace Account", and
"Replace All Accounts" menu items comes up (for me at least) with zero width
boxes for the fields member/project/account (whichever is needed), old ?, new
?, and effective date.  It's barely wide enough to click and not wide enought
to see any typing.  Also, the label on the effective date should read
something like:
"Effective date (mm/dd/yy)" because, I think that may be about the only format
that it accepts.  I had originally thought that it was only my NT remote
client that was displaying this zero width behavior ... but this was running
on a Sunray.

2. If I process a "Replace Project" with an effective date of 11/01/01 and
then inspect the "works_on entries for the old project, they show an edate (as
they should) of 11/01/01.  However when I check the bdate of the new project
int he works_on entries, it seems to show up as "Now" ... since this was a
project that I did just create "now" in the "New Projects window", it
certainly seems that the new project shoudl have now as its bdate (I think),
but I'm wondering whether it should have "now" or "11/01/01" at the point at
which it becomed effective.  I can sort of make arguments each way ... and
maybe this is the planned behavior ... but, to be honest, it wasn't what I was
thinking would happen:  My guess would have been that the project entry itself
would have a bdate of when it was actually created ... which I think is most
reasonable.  But the bdate in the works_on table, I would think, represnets
the time when taht works_on entry became effective (which was effectively
"back dated to 11/01/01") even though the project didn't technically exist
until a few moments before "now".

In any event, I  think that this change should have resulted in a few entries
in the adjustments table for this month.
Member florando should have some adjustments of type eq_activity that change
charges from 2DHZ443 to 2DHZ444.
Member maxy should have some adjustment of type training that change from the
same two numbers for some training that occurred during november (actually, it
looks like there was only one such event during november ... although there
may be some december events that also got adjusted, I  suppose.  

I haven't actually checked the ajustment table to doulbe chekc these things
... I'll try to do that in the morning.

Talk to you tomorrow,

John


From mbell at snf.stanford.edu  Thu Dec  6 08:27:26 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Thu, 06 Dec 2001 08:27:26 -0800
Subject: Resource client bug and possible questionable behavior?
References: <3C0F1C64.957D4153@snf.stanford.edu>
Message-ID: <3C0F9C6D.A45E6425@snf.stanford.edu>

John,

I did notice that swing takes the liberty of resizing the window and thus
shrinking the input text boxes to an unreasonable size.  It's about right for a
"complaints box" but I think we want it larger for anything else. If you grab the
corner of the widow and increase the size a little then the boxes increase to a
normal size. It looks like it all depends on the screen settings of the machine
you display it on.  I can change any of the labels, screen sizes, position,
modality, font or darn near anything else. Just let me know what works best for
you. Also I think the help button taks about date format as well so you may want
changes to that as well.

Thanks,

Mike

John Shott wrote:

> Bill and Mike:
>
> I did a bit of work with the resource client and noticed a couple of things:
>
> 1. The window that is used for the "Replace Project", "Replace Account", and
> "Replace All Accounts" menu items comes up (for me at least) with zero width
> boxes for the fields member/project/account (whichever is needed), old ?, new
> ?, and effective date.  It's barely wide enough to click and not wide enought
> to see any typing.  Also, the label on the effective date should read
> something like:
> "Effective date (mm/dd/yy)" because, I think that may be about the only format
> that it accepts.  I had originally thought that it was only my NT remote
> client that was displaying this zero width behavior ... but this was running
> on a Sunray.
>
> 2. If I process a "Replace Project" with an effective date of 11/01/01 and
> then inspect the "works_on entries for the old project, they show an edate (as
> they should) of 11/01/01.  However when I check the bdate of the new project
> int he works_on entries, it seems to show up as "Now" ... since this was a
> project that I did just create "now" in the "New Projects window", it
> certainly seems that the new project shoudl have now as its bdate (I think),
> but I'm wondering whether it should have "now" or "11/01/01" at the point at
> which it becomed effective.  I can sort of make arguments each way ... and
> maybe this is the planned behavior ... but, to be honest, it wasn't what I was
> thinking would happen:  My guess would have been that the project entry itself
> would have a bdate of when it was actually created ... which I think is most
> reasonable.  But the bdate in the works_on table, I would think, represnets
> the time when taht works_on entry became effective (which was effectively
> "back dated to 11/01/01") even though the project didn't technically exist
> until a few moments before "now".
>
> In any event, I  think that this change should have resulted in a few entries
> in the adjustments table for this month.
> Member florando should have some adjustments of type eq_activity that change
> charges from 2DHZ443 to 2DHZ444.
> Member maxy should have some adjustment of type training that change from the
> same two numbers for some training that occurred during november (actually, it
> looks like there was only one such event during november ... although there
> may be some december events that also got adjusted, I  suppose.
>
> I haven't actually checked the ajustment table to doulbe chekc these things
> ... I'll try to do that in the morning.
>
> Talk to you tomorrow,
>
> John



From bmurray at snf.stanford.edu  Thu Dec  6 13:44:02 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 6 Dec 2001 13:44:02 -0800 (PST)
Subject: Resource client bug and possible questionable behavior?
In-Reply-To: <3C0FD4C3.AA37073@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10112061340370.30986-100000@snf.stanford.edu>

John,

I have made this correction in the replaceProjectForMember,
replaceAccountForProject, and replaceAccount methods.  It compiles
and has been checked in.  It was a little trickier than I had expected
so we should test it before placing it back in production.

I'm working on the last change we discussed: the lab time adjustments.
I hope to finish that this afternoon.

Bill



On Thu, 6 Dec 2001, John Shott wrote:

> Bill:
> 
> The thinking that I have done since our phone conversation reached the same
> conclusion ... that if the effective date is earlier than the works_on (or
> charges_to) bdate, that we should change it to that earlier date.  
> 
> Thanks,
> 
> John
> 



From shott at snf.stanford.edu  Sun Dec  9 10:36:30 2001
From: shott at snf.stanford.edu (John Shott)
Date: Sun, 09 Dec 2001 10:36:30 -0800
Subject: [Fwd: Your Report: Keytool storage insconsistency -- Follow up of 
 internal ID 137016]
Message-ID: <3C13AF2E.67BDD8FA@snf.stanford.edu>

Bill and Mike:

I submitted a bug report to Sun related to the keytool problem that we saw.
I ran an experiment on guilden:

1. Generate a key with 1.4.0-beta3 version of the keytool.

2. List it with the 1.4.0-beta3 version ... things are OK.

3. List it with the 1.2.2. version of keytool ... Owner and Issuer fields are
all encoded as Hex rather than strings.  (Note: this is what we saw with a
downloaded certificate on my NT running JDK 1.3.0.

Note: I also confirmed that the 1.4.0-beta3 keytool can properly read a key
generated with an earlier keytool.

My guess is that the 1.4.0-beta3 is somehow storing the keys in a format that
it can read properly but is inconsistent with the what other versions are
expecting to see.

In any event, I think that this is their bug and I couldn't find any bug
reports on this topic so I thought that we'd better submit it ASAP in hopes
that it is fixed by the time that the release candidate is released.

Thanks,

John
-------------- next part --------------
An embedded message was scrubbed...
From: "IncidentDaemon at sun.com" <IncidentDaemon at sun.com>
Subject: Your Report: Keytool storage insconsistency -- Follow up of internal ID 137016
Date: Sun, 9 Dec 2001 11:28:51 -0700 (MST)
Size: 9327
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20011209/5a60f056/attachment.mht>

From bmurray at snf.stanford.edu  Sun Dec  9 11:09:59 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sun, 9 Dec 2001 11:09:59 -0800 (PST)
Subject: [Fwd: Your Report: Keytool storage insconsistency -- Follow up
 of  internal ID 137016]
In-Reply-To: <3C13AF2E.67BDD8FA@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10112091109460.12313-100000@snf.stanford.edu>

John,

Thanks!

Bill




From shott at snf.stanford.edu  Mon Dec 10 09:29:14 2001
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 10 Dec 2001 09:29:14 -0800
Subject: Resource client bug and possible questionable behavior?
References: <3C0F1C64.957D4153@snf.stanford.edu> <3C0F9C6D.A45E6425@snf.stanford.edu>
Message-ID: <3C14F0EA.C86AB39C@snf.stanford.edu>

Mike:

It is interesting to me that you do set a "preferred size" of 15 characters
for all of these text fields.  This, however, gets overridden by the overall
constraint of a "setPreferredSize(new Dimension(650, 370))" applied to each of
the replace boxes.  On the surface, it appears that this overall
setPreferredSize "wins" relative to the preferred size of the fillin boxes
because there is nothing to tell it that it can't be 650 by 370.  I tried an
experiment on a local version of ReplaceProject.java and eliminated that line
... while the overall window is somewhat smaller, the fillin boxes show up as
their preferred width.  While it is true that shrinking this window causes the
input fields to collapse, I'm inclined to think that this may be better in the
short-term ...

It seems reasonable to me to specify the size of the main applications ... but
it sort of seems that setting the 650, 370 size on the Replace* windows
overspecifys them.

At leaast that's my $.02.

Thanks,

John


> John,
> 
> I did notice that swing takes the liberty of resizing the window and thus
> shrinking the input text boxes to an unreasonable size.  It's about right for a
> "complaints box" but I think we want it larger for anything else. If you grab the
> corner of the widow and increase the size a little then the boxes increase to a
> normal size. It looks like it all depends on the screen settings of the machine
> you display it on.  I can change any of the labels, screen sizes, position,
> modality, font or darn near anything else. Just let me know what works best for
> you. Also I think the help button taks about date format as well so you may want
> changes to that as well.
> 
> Thanks,
> 
> Mike


From cm_richter at yahoo.com  Mon Dec 10 21:34:07 2001
From: cm_richter at yahoo.com (Claudia Richter)
Date: Mon, 10 Dec 2001 21:34:07 -0800
Subject: account problems...help!
Message-ID: <MBBBJCLMICDPMEBHJNHNIEKBCAAA.cm_richter@yahoo.com>

Hi,

I logged in the Coral account this evening and did a word search in
www.yahoo.com and the browser froze. I tried closing the browser, but had no
luck. I tried to log out of Coral, but could not log-out. The log-out window
never appeared. I tried inserting my smart card in other computers and found
that the login screen (with my coral name) also froze. I tried entering my
password and had no luck. I took the smart card and placed it inside the bin
where the 'bad cards' go (by the gowning room).


Claudia
****************
Claudia Richter
Coral name: crichter
Los Gatos Research


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From bmurray at snf.stanford.edu  Mon Dec 10 23:00:21 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 10 Dec 2001 23:00:21 -0800 (PST)
Subject: account problems...help! (fwd)
Message-ID: <Pine.LNX.4.04.10112102257540.4380-100000@snf.stanford.edu>

John,

She had about 20 processes running on the sunray.  (None of which were
java or coral.)  A number appeared to be related to netscape including
dns helper.  I killed all her jobs.  I imagine she'll be ok now.  I'm not
sure what to tell her.  (Don't touch anything?)

Bill

---------- Forwarded message ----------
Date: Mon, 10 Dec 2001 21:34:07 -0800
From: Claudia Richter <cm_richter at yahoo.com>
To: coral at snf.stanford.edu
Subject: account problems...help!

Hi,

I logged in the Coral account this evening and did a word search in
www.yahoo.com and the browser froze. I tried closing the browser, but had no
luck. I tried to log out of Coral, but could not log-out. The log-out window
never appeared. I tried inserting my smart card in other computers and found
that the login screen (with my coral name) also froze. I tried entering my
password and had no luck. I took the smart card and placed it inside the bin
where the 'bad cards' go (by the gowning room).


Claudia
****************
Claudia Richter
Coral name: crichter
Los Gatos Research


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




From tkramer at stanford.edu  Tue Dec 11 12:55:49 2001
From: tkramer at stanford.edu (Theresa Kramer)
Date: Tue, 11 Dec 2001 12:55:49 -0800 (PST)
Subject: mailing list problems
Message-ID: <Pine.GSO.4.33.0112111252490.18095-100000@saga12.Stanford.EDU>

Hi,

I appear to have been bounced off a number of mailing lists for snf
(gryphon, labusers, etc), although I think I am still on some.  I think
what happened is that the address that tkramer at snf forwards to has had a
few outages, and the bounced messages from snf caused me to be deleted
from those lists.

Two requests
1.  Please change my forwarding address on tkramer at snf from
tkramer at jumpjibe.stanford.edu to tkramer at stanford.edu.

2. How do I get reinstated on these lists?  I'm missing key information,
and I really need to be receiving it!

Theresa



From shott at snf.stanford.edu  Tue Dec 11 13:29:47 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 11 Dec 2001 13:29:47 -0800
Subject: mailing list problems
References: <Pine.GSO.4.33.0112111252490.18095-100000@saga12.Stanford.EDU>
Message-ID: <3C167ACB.C2755CB5@snf.stanford.edu>

Theresa:

Following it the output of a script that I have written that checks to see
what mailiing lists you are subscribed to and lists them all out.  Are there
lists over and above these to which you believe you should be on?  I don't
think that we automatically remove anyfrom a list if they get bounced mail. 
So, I'm more suspicious that the problem may be at the jumpjibe end.

In any event, although this wasn't the case when I ran this script, I have now
changed your forwarding so that it gets sent to tkramer at stanford.edu.

Thanks,

John


About to check lists for user tkramer ... 
Note: Mail for tkramer is forwarded by qmail to: tkramer at jumpjibe.stanford.edu

    Mailing list afm
    Mailing list afm2
    Mailing list amtetcher
    Mailing list dektak
    Mailing list drytek2
    Mailing list ebeam
    Mailing list ellipsomter
    Mailing list evalign
    Mailing list gryphon
    Mailing list headway
    Mailing list headway2
    Mailing list karlsuss
    Mailing list labmembers
    Mailing list lampoly
    Mailing list laurel
    Mailing list lithosolv
    Mailing list matrix
    Mailing list oai
    Mailing list semhitachi
    Mailing list svgcoat
    Mailing list svgdev
    Mailing list svgdev2
    Mailing list tylan1
    Mailing list tylan2
    Mailing list tylan3
    Mailing list tylan4
    Mailing list tylan7
    Mailing list tylanbpsg
    Mailing list tylanfga
    Mailing list tylannitride
    Mailing list tylanpoly
    Mailing list tystar1
    Mailing list ultratech
    Mailing list ultratech2
    Mailing list wafersaw
    Mailing list wbdiff
    Mailing list wbgaascl
    Mailing list wbgen-hpl
    Mailing list wbgen-hpr
    Mailing list wbgeneral
    Mailing list wbmetal
    Mailing list wbmiscres
    Mailing list wbnonmetal
    Mailing list wbsilicide


From shott at snf.stanford.edu  Tue Dec 11 13:42:41 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 11 Dec 2001 13:42:41 -0800
Subject: University of Albany ....
Message-ID: <3C167DD1.BFE6F7AF@snf.stanford.edu>

Bill and Mike:

I've had a phone call from Tim Stoner at the lab at the University of Albany
(I think that it may be one of the SUNY campuses) who are eager to get/run
Coral.

I told them that we were in the process of getting MIT and PSU operational and
then we would probalby be in a position to work with them.

This may be an interesting test ... they are an IBM shop: Will run this on an
RS/6000 running AIX and they want to use DB2.  Although Tim Stoner is the lab
manager, they apparently have a manager of their RS/6000 "SuperComputer" ...
gee, I thought it was a workstation or simply a server ... I've told them that
it will be thier responsibility to ultimately convert our SQL table setup
stuff and stored procedures into the DB2 dialect of SQL ... and he seemed
happy to commit to do that.

So, we are getting a number of customers lined up ...

Talk to you later,

John


From bchui at california.com  Tue Dec 11 18:30:46 2001
From: bchui at california.com (Benjamin Chui)
Date: Tue, 11 Dec 2001 18:30:46 -0800
Subject: Problems with netscape on Coral
Message-ID: <web-19852861@california.com>

Hi,

    I notice that more and more websites are causing
problems with coral's version of netscape (causes netscape
to crash and exit, and the user has to restart netscape).

    For example, today's version of www.Yahoo.com will crash
netscape.  I think it's because Yahoo is putting more and
more animated Java ads on its website, and coral's version
of netscape cannot handle the complex Java software.

Ben Chui
bchui at coral


From shott at snf.stanford.edu  Mon Dec 17 10:21:46 2001
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 17 Dec 2001 10:21:46 -0800
Subject: Coral Database docs ...
Message-ID: <3C1E37BA.12AF4E6D@snf.stanford.edu>

Bill and Mike:

I've got a start on a document called "Coral Database Requirements and Setup"
... it isn't yet complete, but I'd appreciate any preliminary comments,
reactions, etc.

Thanks,

John


From shott at snf.stanford.edu  Wed Dec 19 13:48:38 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 19 Dec 2001 13:48:38 -0800
Subject: Remote client bug?
Message-ID: <3C210B36.A04F9C3E@snf.stanford.edu>

Bill and Mike:

I believe that I am having a bit of a problem with the remote version of the
resouce client.

Following is the pertinent section of a log where I first click on "parco" and
then select "Edit member" ... with the following error, then click on a
project (I forget which one) and then select "Edit project" and then click on
an account and select "Edit account".

My suspicion is that we are looking at an Objuscation problem if, as appears,
it is specifically looking for labnet.resource.client.MemberAddModel, etc. 
After obfactaion that is probably something like labnet.c.f.ab.

In fact, I believe that the problem occurs in ResourcePanel.java with the
setModel method where we set the string aModel and eModel to strings similar
to the above ...

We can tell it explicitly to not obfuscate
labnet.resource.client.MemberAddModel and friends ... which will clearly work
... but it may end up in failing to obfuscate more than we hope.

If you believe my diagnosis, I'd be happy to try to modify the obfuscation
code to see if this fixes it ...
Alternatively, is there a reasonable alternative that doesn't require the use
of the full, specific class name?


Note: at first I though it was strange that the ClassNotFoundException was
looking for MemberAddModel ... when I was doing an edit.  However, I think
that this is consisent with the setModel diagnosis as setModel sets Add, Edit,
(and, commented out, Delete) models, in that order ... so it throws the
exception when it looks for the "Add" classs first.  My guess that this is
causing problems elsewhere in the remote resource client becuase, I'll bet, we
call setModel anytime we move from panel to panel.

In any event, here is the error message ... 

John

Starting resource client here!
ADMMGR_IOR_LOC: http://labadmin.stanford.edu/
java.lang.ClassNotFoundException: labnet.resource.client.MemberAddModel
Couldn't find Member with name: parco.
Exception occurred during event dispatching:
java.lang.NullPointerException
	at java.awt.Container.addImpl(Unknown Source)
	at java.awt.Container.add(Unknown Source)
	at labnet.i.a.cl.a(cl.java)
	at labnet.i.a.bd.actionPerformed(bd.java)
	at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
	at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown
Source)
	at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
	at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
	at javax.swing.AbstractButton.doClick(Unknown Source)
	at
javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMouseHandler.menuDragMouseReleased(Unknown
Source)
	at javax.swing.JMenuItem.fireMenuDragMouseReleased(Unknown Source)
	at javax.swing.JMenuItem.processMenuDragMouseEvent(Unknown Source)
	at javax.swing.JMenuItem.processMouseEvent(Unknown Source)
	at javax.swing.MenuSelectionManager.processMouseEvent(Unknown Source)
	at javax.swing.plaf.basic.BasicMenuUI$MouseInputHandler.mouseReleased(Unknown
Source)
	at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
java.lang.ClassNotFoundException: labnet.resource.client.ProjectAddModel
Couldn't find Project with name: 9VAV215.
Exception occurred during event dispatching:
java.lang.NullPointerException
	at java.awt.Container.addImpl(Unknown Source)
	at java.awt.Container.add(Unknown Source)
	at labnet.i.a.cl.a(cl.java)
	at labnet.i.a.bd.actionPerformed(bd.java)
	at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
	at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown
Source)
	at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
	at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
	at javax.swing.AbstractButton.doClick(Unknown Source)
	at
javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMouseHandler.menuDragMouseReleased(Unknown
Source)
	at javax.swing.JMenuItem.fireMenuDragMouseReleased(Unknown Source)
	at javax.swing.JMenuItem.processMenuDragMouseEvent(Unknown Source)
	at javax.swing.JMenuItem.processMouseEvent(Unknown Source)
	at javax.swing.MenuSelectionManager.processMouseEvent(Unknown Source)
	at javax.swing.plaf.basic.BasicMenuUI$MouseInputHandler.mouseReleased(Unknown
Source)
	at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
java.lang.ClassNotFoundException: labnet.resource.client.AccountAddModel
Couldn't find Account with name: 1DAA610.
Exception occurred during event dispatching:
java.lang.NullPointerException
	at java.awt.Container.addImpl(Unknown Source)
	at java.awt.Container.add(Unknown Source)
	at labnet.i.a.cl.a(cl.java)
	at labnet.i.a.bd.actionPerformed(bd.java)
	at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
	at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown
Source)
	at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
	at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
	at javax.swing.AbstractButton.doClick(Unknown Source)
	at
javax.swing.plaf.basic.BasicMenuItemUI$MenuDragMouseHandler.menuDragMouseReleased(Unknown
Source)
	at javax.swing.JMenuItem.fireMenuDragMouseReleased(Unknown Source)
	at javax.swing.JMenuItem.processMenuDragMouseEvent(Unknown Source)
	at javax.swing.JMenuItem.processMouseEvent(Unknown Source)
	at javax.swing.MenuSelectionManager.processMouseEvent(Unknown Source)
	at javax.swing.plaf.basic.BasicMenuUI$MouseInputHandler.mouseReleased(Unknown
Source)
	at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
Exiting normally.


From shott at snf.stanford.edu  Wed Dec 19 17:15:55 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 19 Dec 2001 17:15:55 -0800
Subject: Remote coral and obfuscation ...
Message-ID: <3C213BCB.C69C88DB@snf.stanford.edu>

Bill and Mike:

I've updated, tested (on the development side), and checked in two files to
work around the obfuscation problem that I outlined earlier.

The new files that you should get from me with an update are:
	labnet/Makefile
	labnet/support/conf/script_zkm.txt
The modifications in the script_zkm.txt tell it not to obfuscate classes
labnet.resource.client.MemberAddModel and variations of this with combinations
of Member/Project/Account Add/Edit/Delete.

I modified the makefile to do two things:
	Make obfuscation depend on a more recenter version of the script file (in
addition to the jar file.  Also, I've stored the logs from obfuscation in
/var/log/labnet/build instead of simply /var/log/labnet so they aren't in the
way of normal log files.  One of them that may be useful at some point is
called ZKMConversions.log ... this file is the magic decoder ring of which
class files got renamed to which obfuscated names.  If someone reports that
they had a remote error that reported that class labnet.a.a.a reported a null
pointer exception, we can look there and find that labnet.a.a.a is actually
labnet.auth.ticket.DTD ... which you probably wouldn't guess just by looking
at it.

Thanks,

John


From shott at snf.stanford.edu  Wed Dec 19 17:32:56 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 19 Dec 2001 17:32:56 -0800
Subject: Error when remote clients run JDK 1.4 ...
Message-ID: <3C213FC8.39001D3C@snf.stanford.edu>

Bill and Mike:

At the moment, anyone running a remote client on JDK1.4.0 will see the
following error because it installs the Sun jce.jar automatically.

The error that occurs (in terms of the error that the user sees) is:
"Unable to make a secure connection. Please see the lab staff."
In their log file they will see something like:

Unable to construct an encryption object.
java.security.NoSuchProviderException: JCE cannot authenticate the provider
ABA java.util.jar.Exception
File long_name/DMlib/RMjce.zip is not signed by a trusted signer.
Unable to initialize BlackBox


The way that I currently get around this on my linux box (and the way that we
avoid any of these issues on sunray/rosen and friends is to rename
$JAVA_HOME/jre/lib/jce.jar to $JAVA_HOME/jre/lib/jce.jar.orig.  This approach
will likely not be viable for most of our remote clientele ...

It appears as if the solution for people running 1.4 is the covert to Bouncy
Castle (that has a signed jar file ... signed by sun.).  Of course, we don't
yet know if the Bouncy Castle implementation of RSA results in the same
encrypted/decrypted passwords as the ABA implementation.

Also, while that is probably the approach for people who do have JDK 1.4, we
would then have (I think) the backward compatability problem of people still
running 1.3 who, presumably, don't have JCE installed.

Since I gather that some of the ABA folks have now thrown in with Bouncy
Castle, I may see if they happen to know the answer to this ...

While I don't know yet what our best approach will be, I wanted to at least
try to save some trouble if you get a report of a remote client failing in ths
way.

John


From bmurray at snf.stanford.edu  Wed Dec 26 17:07:10 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 26 Dec 2001 17:07:10 -0800 (PST)
Subject: Bug Fixes
Message-ID: <Pine.LNX.4.04.10112261703020.1516-100000@snf.stanford.edu>

John and Mike,

I fixed a bug I introduced during the last round of changes.  The fix has 
been tested and installed and is running on rosen.  The bug left a few bad
records in current_lab which I have removed.  I also found and fixed a 
couple of minor problems in the event polling code related to error 
recovery.  (While I was in the client code, I commented out some unneccessary
debugging.)  

Now I'm moving on to the Postgres stuff.

Bill