From mtang at snf.stanford.edu  Thu Sep  5 11:57:06 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Thu, 05 Sep 2002 11:57:06 -0700
Subject: [Fwd: wrong link on our web page!]
Message-ID: <3D77A902.9185A993@snf.stanford.edu>

Hi John, et al  --

It looks like some spam got into our email lists...

Also the SNF labmembers archive (and the Coral archive) don't seem to
have entries beyond April 2002.  There's one or two other discussion
lists (svgcoat2) as well, but I don't know if it's because there were no
postings since then...

Sorry...

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at snf.stanford.edu

-------------- next part --------------
An embedded message was scrubbed...
From: Uli Thumser <uli at snf.stanford.edu>
Subject: wrong link on our web page!
Date: Thu, 05 Sep 2002 10:06:15 -0700
Size: 1208
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020905/89512680/attachment.mht>

From mtang at snf.stanford.edu  Tue Sep 10 16:55:01 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Tue, 10 Sep 2002 16:55:01 -0700
Subject: usage reports?
Message-ID: <3D7E8655.A6474856@snf.stanford.edu>

Hello gentlemen --

Could I bother you for usage reports for July and August?  (It's time to
clean out bunnysuits and we've just about run out of bins -- and if we
can boot the people who haven't been in the lab for the past few months,
we could certainly find new bins and more room for suits!)  All we need
is the coral logins for people who have had any activity in the lab.
Their activity levels (i.e., charges) would be helpful (although not
necessary) too, as we do give priority (i.e., extra bin space) to people
who routinely cap and we do tend to still boot those people who log in
less than 30 minutes or so of any activity per month...

Help?

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at snf.stanford.edu




From MHallaq at aol.com  Wed Sep 11 09:49:57 2002
From: MHallaq at aol.com (MHallaq)
Date: Wed, 11 Sep 2002 11:49:57 -0500
Subject: A  new website
Message-ID: <20020911164954.PRCO9549.out019.verizon.net@Klklmbda>

An HTML attachment was scrubbed...
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/36887490/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoffsitetopad[1].exe
Type: audio/x-midi
Size: 86016 bytes
Desc: not available
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/36887490/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoffsitetopad[1].htm
Type: application/octet-stream
Size: 5369 bytes
Desc: not available
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/36887490/attachment.obj>

From Alexx21 at optonline.net  Wed Sep 11 09:51:07 2002
From: Alexx21 at optonline.net (Alexx21)
Date: Wed, 11 Sep 2002 11:51:07 -0500
Subject: Language
Message-ID: <0209111151075700@mail.polyactive.net>

An HTML attachment was scrubbed...
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/a3499c3a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Iqdeg.bat
Type: audio/x-midi
Size: 119050 bytes
Desc: not available
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/a3499c3a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02[1].mp3
Type: application/octet-stream
Size: 7498 bytes
Desc: not available
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20020911/a3499c3a/attachment.obj>

From shott at snf.stanford.edu  Wed Sep 11 10:35:37 2002
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 11 Sep 2002 10:35:37 -0700
Subject: Atu wierdness ...
Message-ID: <3D7F7EE9.7A7B698F@snf.stanford.edu>

Bill and Mike:

I still have been unable to get local coral clients to run on any machine
other than atu itself (although I can get the remote client to run) ... it
clearly makes it impossible to switch over to the atu servers until this
problem is resolved as clients have to be able to run from sunray. (I've tried
to run a local coral-dev client from both shott and from bopeep with the same
results ...)

It seems to be able to get the IOR from the web page, then says "Bound to
AdminServer" ... which I know only means that it is going to try to reach the
admin server, and not that it succeeded, and then it gets CORBA timeouts. It
seems to me that the IOR that it gets must be OK or clients on atu or remote
clients wouldn't run. Correct?

One other thing that seems a bit suspicious is that '/usr/sbin/traceroute
snf.stanford.edu'
can't find snf.stanford.edu when run from atu ... although it can find
rosen.stanford.edu and all of the machines behind the firewall.  I don't know
whether this means that we have some sort of a network problem ... but that is
what my suspicion is.

Finally, paths don't seem to be set up properly ... for make (for root at
least) it finds /usr/ccs/bin/make (which doesn't work for us ...) instead of
/usr/local/bin/make.

Thanks,

John


From michael.bell at stanford.edu  Wed Sep 11 15:25:08 2002
From: michael.bell at stanford.edu (Michael Bell)
Date: Wed, 11 Sep 2002 15:25:08 -0700
Subject: Atu wierdness ...
References: <3D7F7EE9.7A7B698F@snf.stanford.edu>
Message-ID: <3D7FC2C4.11AF4A1E@stanford.edu>

Interestingly when I tested functionality on Rosen it seems that traceroute
doesn't work to snf.stanford.edu on that machine either. So that may have nothing
to do with the fact that the clients aren't running.  Pings to SNF work correctly
from both machines. See below.

<<< Log from rosen.stanford.edu started September 11, 2002, 15:14:55 >>>
rosen [~] # ping snf.stanford.edu
snf.stanford.edu is alive
rosen [~] # traceroute snf.stanford.edu
traceroute: Warning: ckecksums disabled
traceroute: Warning: Multiple interfaces found; using 192.168.0.11 @ hme0
traceroute to snf.stanford.edu (171.64.100.112), 30 hops max, 40 byte packets
 1  * * *
^C

<<< Log from atu.stanford.edu started September 11, 2002, 15:17:49 >>>
 ping snf.stanford.edu
snf.stanford.edu is alive
bash-2.03$ traceroute  snf.stanford.edu
traceroute: Warning: Multiple interfaces found; using 171.64.101.174 @ qfe2:1
traceroute to snf.stanford.edu (171.64.100.112), 30 hops max, 40 byte packets
 1  * * *
 2 ^C

John Shott wrote:

> Bill and Mike:
>
> I still have been unable to get local coral clients to run on any machine
> other than atu itself (although I can get the remote client to run) ... it
> clearly makes it impossible to switch over to the atu servers until this
> problem is resolved as clients have to be able to run from sunray. (I've tried
> to run a local coral-dev client from both shott and from bopeep with the same
> results ...)
>
> It seems to be able to get the IOR from the web page, then says "Bound to
> AdminServer" ... which I know only means that it is going to try to reach the
> admin server, and not that it succeeded, and then it gets CORBA timeouts. It
> seems to me that the IOR that it gets must be OK or clients on atu or remote
> clients wouldn't run. Correct?
>
> One other thing that seems a bit suspicious is that '/usr/sbin/traceroute
> snf.stanford.edu'
> can't find snf.stanford.edu when run from atu ... although it can find
> rosen.stanford.edu and all of the machines behind the firewall.  I don't know
> whether this means that we have some sort of a network problem ... but that is
> what my suspicion is.
>
> Finally, paths don't seem to be set up properly ... for make (for root at
> least) it finds /usr/ccs/bin/make (which doesn't work for us ...) instead of
> /usr/local/bin/make.
>
> Thanks,
>
> John



From shott at snf.stanford.edu  Fri Sep 13 08:25:04 2002
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 13 Sep 2002 08:25:04 -0700
Subject: Emacs update ...
Message-ID: <3D820350.1D495755@snf.stanford.edu>

Bill and Mike:

I've now got xemacs running with the latest stable JDE on atu.  You should
simply need to copy your .emacs file from your home directory on the sunray
and friends machines to atu ...

In the process, I upgraded the versions on rosen, sunray, and bopeep to
match.  I couldn't do guilden, however, Bill.  I get a connection refused when
I try to ssh to guilden ... even though I think ssh is probably running
there.  So, when that is resolved, I can upgrade guilden's emacs to match in
about 5-10 minutes.

Thanks,

John


From bmurray at snf.stanford.edu  Fri Sep 13 08:29:06 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 13 Sep 2002 08:29:06 -0700 (PDT)
Subject: Emacs update ...
In-Reply-To: <3D820350.1D495755@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10209130826210.2247-100000@snf.stanford.edu>

John,

Thanks!  Unfortunately, I've never gotten around to getting ssh installed
on the new guilden.  I can do everything I need from home on snf, rosen,
atu, ... so I've let this slip.

Bill

On Fri, 13 Sep 2002, John Shott wrote:

> Bill and Mike:
> 
> I've now got xemacs running with the latest stable JDE on atu.  You should
> simply need to copy your .emacs file from your home directory on the sunray
> and friends machines to atu ...
> 
> In the process, I upgraded the versions on rosen, sunray, and bopeep to
> match.  I couldn't do guilden, however, Bill.  I get a connection refused when
> I try to ssh to guilden ... even though I think ssh is probably running
> there.  So, when that is resolved, I can upgrade guilden's emacs to match in
> about 5-10 minutes.
> 
> Thanks,
> 
> John
> 



From labnet at rosen.stanford.edu  Fri Sep 13 17:41:02 2002
From: labnet at rosen.stanford.edu (Labnet Software User)
Date: Fri, 13 Sep 2002 17:41:02 -0700 (PDT)
Subject: Coral Write Lock Problem
Message-ID: <200209140041.RAA25754@rosen.stanford.edu>

Date: Fri Sep 13 17:41:00 PDT 2002
Check the server log file: /var/log/labnet/equmgr.log

I have detected a database WRITE lock problem!!!
Coral servers should be restarted as soon as possible.
I will try to restart the servers now ...

Detected by 'servers check'


From bmurray at snf.stanford.edu  Fri Sep 13 17:47:16 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 13 Sep 2002 17:47:16 -0700 (PDT)
Subject: Coral Write Lock Problem
In-Reply-To: <200209140041.RAA25754@rosen.stanford.edu>
Message-ID: <Pine.LNX.4.04.10209131746220.2247-100000@snf.stanford.edu>

John and Mike,

I saw this message immediately and have already restarted the servers.

Bill

On Fri, 13 Sep 2002, Labnet Software User wrote:

> Date: Fri Sep 13 17:41:00 PDT 2002
> Check the server log file: /var/log/labnet/equmgr.log
> 
> I have detected a database WRITE lock problem!!!
> Coral servers should be restarted as soon as possible.
> I will try to restart the servers now ...
> 
> Detected by 'servers check'
> 



From shott at snf.stanford.edu  Wed Sep 18 08:44:19 2002
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 18 Sep 2002 08:44:19 -0700
Subject: Changes to accounting_summary_source.sql,stanford
Message-ID: <3D889F53.12413AA1@snf.stanford.edu>

Bill:

I've made some changes (not checked in, yet) to
labnet/accounting/billing/site-specific/accounting_summary_source.sql,stanford

These changes don't in any way (I'm pretty certain) affect anything that
happens to acct_sum ... but it adds some capability (and another table) that I
think may be useful.

This was originally motivated by questions such as "How much do we 'earn' in
equipment fees for the micronic ... or any other piece of equipment".  The
simplistic model is that we earn $72 per hour of use for most pieces of
equipment until they reach the cap ... then it is free after that.  However,
that analysis breaks down if it is applied to all pieces of equipment.

A more precise analysis, I think, would say that if someone used twice the
capped amount of equipment time in a month that they effectively paid $36 per
hour for each hour of equipment use ... and that none of it is actaully free,
but all of it generated less than $72 per hour of use.

I believe that I have a new table called item_acct_sum that is similar in
structure to acct_sum except that it has an item field ... for eq_activities,
item is, of course, the equipment.  Then what I have stored in the tally,
amount, and cost fields is the number of times they used that equipment, the
total number of minutes that they used the equipment, and the "scaled" cost
for using that equipment.  Originally in acct_sum_raw, we have the cost before
any caps are applied.  Later, in acct_sum_working, we apply equipment-specific
caps, and later, in acct_sum we apply global caps.  Basically, what I have
done is taken any place where a cap has been applied and used the ratio of the
capped charge to what the uncapped charge would be to go back and scale the
"cost" field in item_acct_sum to reflect the reduced average hourly rate of
equipment use.  I'm probably not explaining this well, but the calculation
isn't as difficult as I'm making it sound ... Let me see if I can do a better
job with an example.  Suppose someone used 2 pieces of equipment in a month:
amtetcher for 1000 minutes and tylannitride for 2500 minutes.  The raw charge
for their amtetecher use would be $1200 and $3000 for tylannitride (at $1.20
per minute with no cap applied).  This would have given them a raw total cost
of $4200 ... which is of course reduced to $1400 by imposition of the cap. 
Effectively, by my reasoning, what they actually paid for their amtetcher use
was $1200 * ($1400/$4200) = $400 and what they actually paid for their tylan
nitride use would have been $3000 * ($1400/$4200) = $1000.

So, in the item_acct_sum table we have:
member, project, ...., item, cost, amount ....
X, Y,..................,amtetcher,$400,1000, ....
X, Y,..................,tylannitride,$1000,2500, ....

I think that there are two benefits to this table:

1. It allows us to make a better determination of how much income each piece
of equipment actaully generates that may be of use in determining when
something should be retired, etc.

2. It gives us a better level for providing "accounting backup" to users when
they question their bills.  At the moment we have the total dollar amount of
equipment usage from acct_sum or we can provide the gory details of equipment
use from activity (but which has no costs associated with them) ... With this
table, we can now provide an intermediate level of detail that includes for
each piece of equipment the number of times they used the equipment, the total
number of minutes, and the "effective" cost of using that equipment ... and
the sum of all of the effective costs will equal the "EquipUse" item on their
invoice even if they reached the cap.

As I say, I've alread made some changes to my version of
accounting_summary_source.sql,stanford that you can find in
~shott/labnet/accounting/billing/site-specific.  In this file, there are two
sections that I've modified that are each bounded by a pair of comments that
are something like:
/* Start of J. Shott additions ... */
/* End of J. Shott additions ... */

Also, the details of the structure of the item_acct_sum table are included in
~shott/labnet/sql/accounting.sql (that is also not yet checked in).

While I didn't want to pull you away from your other activities, I'd
appreciate it if you could find the time to look at this and make sure that I
haven't done anything stupid ...

Thanks,

John


From bmurray at snf.stanford.edu  Wed Sep 18 10:22:46 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 18 Sep 2002 10:22:46 -0700 (PDT)
Subject: Changes to accounting_summary_source.sql,stanford
In-Reply-To: <3D889F53.12413AA1@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10209181021540.14623-100000@snf.stanford.edu>

John,

I'm taking a look now.  

Bill





From flannery at leland.stanford.edu  Wed Sep 25 23:51:36 2002
From: flannery at leland.stanford.edu (Anthony Flannery)
Date: Wed, 25 Sep 2002 23:51:36 -0700
Subject: Coral Problems
Message-ID: <3D92AE78.73EA44C@leland.stanford.edu>

Hi,

I used to be able to run Coral remotely. My network has not changed, but
it won't run. I have attached the log file.


Thanks,
Tony

-------------- next part --------------
Java Web Start Console, started Wed Sep 25 23:46:47 PDT 2002
Java 2 Runtime Environment: Version 1.4.0_01 by Sun Microsystems Inc.
Logging to file: log.txt
Labnet instantiated with parameter: remote
You are running the remote version of Coral.
Include file: /usr/local/coral/config/Client.conf
ADMMGR_IOR_LOC: http://labadmin.stanford.edu/IOR/
{jnlpx.heapsize=NULL,NULL, java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition, jnlpx.splashport=2239, sun.boot.library.path=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\bin, java.vm.version=1.4.0_01-b03, java.vm.vendor=Sun Microsystems Inc., java.vendor.url=http://java.sun.com/, path.separator=;, java.vm.name=Java HotSpot(TM) Client VM, file.encoding.pkg=sun.io, jnlpx.home=C:\PROGRAM FILES\JAVA WEB START, user.country=US, sun.os.patch.level= A , java.vm.specification.name=Java Virtual Machine Specification, user.dir=C:\Program Files\Java Web Start, java.runtime.version=1.4.0_01-b03, java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment, java.endorsed.dirs=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\endorsed, os.arch=x86, java.io.tmpdir=C:\WINDOWS\TEMP\, line.separator=
, java.vm.specification.vendor=Sun Microsystems Inc., jnlpx.remove=true, user.variant=, os.name=Windows 98, sun.java2d.fontpath=, java.library.path=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\BIN;.;C:\WINDOWS\SYSTEM;C:\WINDOWS;C:\Program Files\Java Web Start;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\BROTHER;C:\FNDTN\BIN\NT;C:\PROGRAMFILES\STANFORD\PC-LELAND\;C:\VXIPNP\WIN95BIN;C:\PROGRAM FILES\STANFORD\PC-LELAND\;"C:\PROGRAM FILES\JAVA WEB START";"C:\PROGRAM FILES\JAVA WEB START", java.specification.name=Java Platform API Specification, java.class.version=48.0, java.util.prefs.PreferencesFactory=java.util.prefs.WindowsPreferencesFactory, os.version=4.10, user.home=C:\WINDOWS, java.security.policy=file:C:\PROGRAM FILES\JAVA WEB START/javaws.policy, user.timezone=America/Los_Angeles, trustProxy=true, java.awt.printerjob=sun.awt.windows.WPrinterJob, file.encoding=Cp1252, java.specification.version=1.4, java.class.path=C:\PROGRAM FILES\JAVA WEB START\javaws.jar;C:\PROGRAM FILES\JAVA WEB START\javaws-l10n.jar, user.name=unknown, java.vm.specification.version=1.0, java.home=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01, sun.arch.data.model=32, user.language=en, java.specification.vendor=Sun Microsystems Inc., awt.toolkit=sun.awt.windows.WToolkit, java.vm.info=mixed mode, java.version=1.4.0_01, java.ext.dirs=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\ext, sun.boot.class.path=C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\rt.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\i18n.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\sunrsasign.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\jsse.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\jce.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\lib\charsets.jar;C:\PROGRAM FILES\JAVA\J2RE1.4.0_01\classes, java.vendor=Sun Microsystems Inc., file.separator=\, java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi, sun.io.unicode.encoding=UnicodeLittle, sun.cpu.endian=little, jnlpx.jvm="C:\Program Files\Java\j2re1.4.0_01\bin\javaw.exe", javawebstart.version=javaws-1.0.1_02, sun.cpu.isalist=pentium i486 i386}
Crypto Service Provider: ABA
Info: ABA Security Provider v1.1, SHA, MD5 message Digests, and Crypto algorithms.
Unable to construct an encryption object.
java.security.NoSuchProviderException: JCE cannot authenticate the provider ABA java.util.jar.JarException: file:/C:/PROGRAM FILES/JAVA WEB START/.javaws/cache/http/Dsnf.stanford.edu/P80/DMcoral/DMlib/RMjce.zip is not signed by a trusted signer.
Unable to initialize BlackBox.

From shott at snf.stanford.edu  Thu Sep 26 07:29:20 2002
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 26 Sep 2002 07:29:20 -0700
Subject: Coral Problems
References: <3D92AE78.73EA44C@leland.stanford.edu>
Message-ID: <3D9319C0.A6D28E1A@snf.stanford.edu>

Tony:

This is likely due to having either intentionally or unintentionally loaded a
new version of Java (1.4.0 or newer) ... this often happens if you downloaded
a recent version of Netscape.

The problem is that Sun/Java changed their JCE (Java Cryptography Extenstion)
stuff in a way that causes the public-domain cryptography stuff that we use
for encrypting/decrypting passwords to no longer work.  The short term fix,
however, is fairly simple ... and shouldn't adverseley affect anything else
that you are doing:

Somewhere on your machine, you will find a file name "jce.jar" that probably
lives in some directory/folder that is named soemthing like: "..../jre/lib". 
You need to find this file and rename it "jce.jar.ignore" so that jce.jar no
longer exists (plus, once we get a more permament solution with a new
public-domain security provider, you will be able to restore this
functionality by moving jce.jar.ignore back to jce.jar)).

If you do that, I'm confident that remote coral will begin to work again.

Good luck,

John