From shott at snf.stanford.edu  Wed Jul  4 08:30:14 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 04 Jul 2001 08:30:14 -0700
Subject: [Fwd: [ Announce ] Bouncy Castle Crypto Package Version 1.06 now 
 available]
Message-ID: <3B433686.F09C0BA7@snf.stanford.edu>

Bill and Mike:

Bouncy Castle (I still don't know the origins or meaning of the name) has just
realeased their latest crypto package (that includes RSA) that is both
compatible with the new JDK 1.4 and has a signed certificate from Sun so that
they can be listed as a "real" provider.

While I don't propose that we put this in at the moment ... I think that we
should consider adopting this in the not too distant future.  In particular,
it would allow us to use J2SE out of the box (instead of requiring folks to
"rip out" JCE) which, I think, would make it easier to deploy elsewhere.  Of
course, folks will need to get the bouncy castle stuff ... but they need to
get the ABA stuff already.

One other thing ... we'd need to test to make sure that the RSA
encryption/decryption that Bouncy Castle provides does the same thing as what
the ABA stuff does or we would have to convert evertyhing en-mass.  The Bouncy
Castle folks, however, claim that their encryption/decryption is fully
compatiible with the stuff from RSA, so, if ABA did their job properly, we may
not have a problem ....

Thanks,

John
-------------- next part --------------
An embedded message was scrubbed...
From: "Jon Eaves" <jon at eaves.org>
Subject: [ Announce ] Bouncy Castle Crypto Package Version 1.06 now available
Date: Wed, 4 Jul 2001 22:12:00 +1000
Size: 2872
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010704/5ab8866c/attachment.mht>

From dcaudillo at worldnet.att.net  Thu Jul  5 13:08:06 2001
From: dcaudillo at worldnet.att.net (David Caudillo-Malik)
Date: Thu, 5 Jul 2001 13:08:06 -0700
Subject: Remote coral not working
Message-ID: <000901c1058e$3bb99ec0$f601510c@pavilion>

Time: 13:07 hrs:   May be it's just me. Only from July 3rd have I had a problem with logging into Coral from home. I
begin from the Java Web Start Application Manager then type my user name and password it responds back with a
notification that Authntification Failed. My caps lock is not on. Is there currently a remote access problem? If this
was a peak use period for Coral would I see that same notification?
David Caudillo




From shott at snf.stanford.edu  Thu Jul  5 18:15:50 2001
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 05 Jul 2001 18:15:50 -0700
Subject: Remote coral not working
References: <000901c1058e$3bb99ec0$f601510c@pavilion>
Message-ID: <3B451146.8CD72826@snf.stanford.edu>

Bill and Mike:

David's problem was due to his default project no longer being a valid project
... he is back on the air.

John


From mbell at snf.stanford.edu  Fri Jul  6 07:10:53 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Fri, 06 Jul 2001 07:10:53 -0700
Subject: [Fwd: Coral does not open up 4/me]
Message-ID: <3B45C6ED.5E47D24B@snf.stanford.edu>

John and Bill,

I thought I should start forwarding this stuff to the CORAL list and
then we can decide how best to handle it.

Mike
-------------- next part --------------
An embedded message was scrubbed...
From: caudillomalik at netscape.net (David Caudillo)
Subject: Coral does not open up 4/me
Date: Thu, 05 Jul 2001 20:11:24 -0400
Size: 1499
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010706/abe43a93/attachment.mht>

From shott at snf.stanford.edu  Fri Jul  6 11:50:23 2001
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 06 Jul 2001 11:50:23 -0700
Subject: utmp and wtmp files ....
Message-ID: <3B46086F.9A4530D6@snf.stanford.edu>

Bill and Mike:

I did a little snooping about the /var/adm/utmp and /var/adm/wtmp files that
get so big.  They basically keep track of logins ... and we have many.

I found a script that seemed pretty reasonable that runs monthly (via cron)
and creates a *.gz of the previous month's activity, truncates the various
files to zero lenght, and then throws away old *.gz files older than 4 months.

I've installed this on sunray, guilden, bopeep, and rosen and manually run it
to take care of the current large files on sunray.  Hopefully this will
eliminate the problem we were seeing on sunray. The two biggest files (wtmp
and wtmpx were reduced from something like 400MB to a total of about 13MB).
We can keep an eye on sunray to see if we need to run this more frequently
....

Thanks,

John


From shott at snf.stanford.edu  Sat Jul  7 10:36:08 2001
From: shott at snf.stanford.edu (John Shott)
Date: Sat, 07 Jul 2001 10:36:08 -0700
Subject: Servers restarted ...
Message-ID: <3B474888.EC0AE8EB@snf.stanford.edu>

Bill and Mike:

I restarted the servers at 10-something this morning.  We appeared to have
died sometime after 3 a.m. once again ... without having conducted an
exhastive search, I'd say that something must be wrong with backup.  Note:
there was no evidence on the screen of the "nfs failure" kind of problems that
we often see.

A reboot of rosen seems to have cured things ...

John


From shott at snf.stanford.edu  Sun Jul  8 18:09:13 2001
From: shott at snf.stanford.edu (John Shott)
Date: Sun, 08 Jul 2001 18:09:13 -0700
Subject: Updated Makefiles ....
Message-ID: <3B490439.884E155C@snf.stanford.edu>

Bill and Mike:

I've made extensive changes to the Makefiles that, I think, take care of the
following changes:

1. We no longer install all of the *.class files ...

2. The "install" directory is now /usr/local/coral rather than home labnet.
Within it are directories lib (the jar files), bin (including the labnet
startup script), sbin (incliding the servers and server_start scripts), etc
(containing all of the configuration stuff), and share (contining the icons).
The only thing, that I no of, that isn't there ... the AdminServerIOR is still
in /home/labnet/share/IOR/AdminServerIOR with a link to
/home/httpd/html/AdminServerIOR.  I think taht this is because bopeep has the
running web server and I didn't know how to readily get the IOR over there
when /usr/local/coral isn't cross-mounted.

3. I've removed the conf directories and included the *.conf file at the
"main" level in each place rather than one-level down.

4. I think that I now support site-specific *.java files, *.sh files (that are
used to create the labnet, server_start and servers scripts), and *.conf
files.  I need to check wether we are yet supporting site-specific *.sql
files.

I think that I've gotten everything to compile, and I've gotten the servers
started (note: at the momemt you have to give the full path to the "servers"
script ... becuase /home/labnet/sbin/servers is the one that it finds by
default.  In other words, issue "/usr/local/coral/sbin/servers start" to start
the new servers ... Of course, this has to be run as root.

I got the client very close to running ... it got connected, and got a ticket
but claims not to know about some class in resource/client.  Check
~shott/.coral-log to see for certain ...  It's getting to be my dinner time so
I haven't fully checked it out.

Oh yes ...  one important reminder.  You have to have the environment variable
SITE set to "stanford".  While we can do this in the shell automatically, you
can do it manually by issuing the command "export SITE=stanford".  Note: if
you want to do a "make prod-install", then root currently has to have this
variable set as well.

Minor point: I added a handful of .cvsignore files so that "cvs update >&
update.log" doesn't complain about too many things.

So, hopefully "cvs checkout -P" will make these changes for you and you won't
find it too painful.

Note: there needs to me more exhaustive testing of this stuff...

See you tomorrow,

John


From shott at snf.stanford.edu  Mon Jul  9 13:04:27 2001
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 09 Jul 2001 13:04:27 -0700
Subject: Rosen problems ....
Message-ID: <3B4A0E4B.56545FED@snf.stanford.edu>

Bill and Mike:

As you are probably aware, rosen died several times over the weekend  ... in
these cases, it appears to correlate with our hme problems that we have seen
intermittently in the past.

I think that it is time to try the suggestions that sun gave us that, as I
recall, were related to running the hme in 32-bit rather than 64-bit mode.

>From what I was on the sunsolve.sun.com bug database, I've added the following
lines to the /etc/system file:

set fas:fas_enable_SBUS65=0
dry hme:hme_64bit_enable=0

The next time rosen dies and has to be rebooted, this will, hopefully take
effect ...

Thanks,

John


From xjzhang at stanford.edu  Wed Jul 11 17:23:34 2001
From: xjzhang at stanford.edu (John XJ Zhang)
Date: Wed, 11 Jul 2001 17:23:34 -0700 (PDT)
Subject: remote access problem
Message-ID: <Pine.GSO.4.31.0107111721200.29157-100000@elaine37.Stanford.EDU>

Hello,

Does Coral "remote access" function work outside campus network? I tried
from home at San Jose but can not get into the network.

Thanks for your help !

****************************************
John XJ Zhang, Ph.D. Candidate
Stanford Microphotonics Lab
Edward L. Ginzton Laboratories, Rm.41-C
Dept. of Electrical Engineering
Stanford University, CA 94305

Tel:    1-650-281-3752
Fax:    1-650-725-7509

Email:  xjzhang at stanford.edu
        xjzhang at stanfordalumni.org
        xjzhang at ieee.org

Mailbox: S-50, Ginzton Lab

Research URL: www.stanford.edu/group/SML/
*****************************************



From liji at intpax.com  Thu Jul 12 10:57:06 2001
From: liji at intpax.com (Liji Huang)
Date: Thu, 12 Jul 2001 10:57:06 -0700
Subject: Remote access
Message-ID: <3B4DE4F2.455E0B58@intpax.com>

Dear Sir/Madam:

I tried to install the remote access on my desktop running a Window NT
4.0
The installation went fine and the remote password also worked. But it
always gave me an error message - equipment information can not acess-
Could you please advise.

Thank you,
Liji Huang
liji at nsf.stanford.edu



From shott at snf.stanford.edu  Thu Jul 12 11:04:27 2001
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 12 Jul 2001 11:04:27 -0700
Subject: Remote access
References: <3B4DE4F2.455E0B58@intpax.com>
Message-ID: <3B4DE6AB.71C9EDD1@snf.stanford.edu>

Liji:

This is the primary sympton of someone who is behind a firewall.  Remote coral
won't work if you are coming to us from behind a firewall.

Is that your situation?

Thanks,

John


From shott at snf.stanford.edu  Thu Jul 12 11:33:36 2001
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 12 Jul 2001 11:33:36 -0700
Subject: Spruced up Makefiles ...
Message-ID: <3B4DED80.8F8C65EB@snf.stanford.edu>

Mike and Bill:

I think that I've found and resolved the bugs that were preventing a clean
build.  Part of the problem was that I hadn't completely finished the
"site-specific" stuff.  Also, my implementation of the "build" directories
wasn't quite right:  In general, the makefiles refer to most directories in
the "build tree" as a relative address: e.g. $(DEPTH)/labnet/ ...
However, in order to run the built version of servers, server_start, and
labnet, they need to have absolute path names in the CLASSPATH values that are
set.  I think I've got this improved now.

So, hopefully and "cvs update -P" will get this modified stuff so taht you get
a clean build.

Thanks,

John


From mtang at snf.stanford.edu  Thu Jul 12 16:26:07 2001
From: mtang at snf.stanford.edu (Mary Tang)
Date: Thu, 12 Jul 2001 16:26:07 -0700
Subject: [Fwd: IR Source for Karl Suss]
Message-ID: <3B4E320F.5520C976@snf.stanford.edu>

Hi Coral Dev Team --

Is this a job for you?  By the way, do we "roll-off" old labmembers?
(I'm assuming this guy's a former user...)

Thanks,

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: Eric Pop <epop at stanford.edu>
Subject: Re: IR Source for Karl Suss 
Date: Thu, 12 Jul 2001 15:42:45 -0700
Size: 1106
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010712/de4d5c12/attachment.mht>

From pruitt at stanford.edu  Fri Jul 13 17:31:33 2001
From: pruitt at stanford.edu (Beth Pruitt)
Date: Fri, 13 Jul 2001 17:31:33 -0700 (PDT)
Subject: Enable Over
Message-ID: <Pine.GSO.4.31.0107131718450.13423-100000@epic10.Stanford.EDU>

I am sure it is on the list, but I'd like to ask that reinstating the
"enable over" function be given a high priority for
implementation.

I had an unfortunate and avoidable loss of 1 of 5 of my last SOI wafers
with 6 of 9 mask levels complete on the developer track the other day.
Someone who meant to disable the other track and enable in her name
accidentally disabled and reenabled my track. This caused the developer to
stop, open the tracks and close the tracks again, or similar actions, thus
dropping the wafer into the bowl and then smashing it on dropping the
bowl--I witnessed the last few seconds of the events but was unclear what
had/was happening in time to stop it. I was pretty bummed to say the
least...

Now, while this wasn't intentional or malicious, I'd argue that 99% of the
time that labmembers disable equipment in someone elses name it is because
they want to use it. Noone has other incentive to go around turning off
equipment that others are/were using.  If this is an extensive fix,
perhaps a labwide email urging caution in disabling and reenabling
equipment in another user's name would help in the meantime. While it
doesn't happen often, the results on much of the equipment can be pretty
severe.

thanks much
Beth Pruitt



From bmurray at snf.stanford.edu  Sun Jul 15 19:36:53 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sun, 15 Jul 2001 19:36:53 -0700 (PDT)
Subject: Status
Message-ID: <Pine.LNX.4.04.10107151928400.25911-100000@snf.stanford.edu>

John and Mike,

Today I finally completed the bulk of the coding for the server side of the
new resource client including setting up the new adjustment table and 
granting access to the rscmgr on both the development and production 
databases.  (This was completely safe because I was just creating a new
table and giving the rscmgr read access to a number of different tables.)
All that remains is about a days worth of cookie cutting, compiling the code,
and chasing down any compiler errors.  I'll be in first thing tomorrow to
complete these activities.  

John, now might be a good time to sneak in the code change that both
Aaron and Beth Pruitt have requested regarding enabling a currently-enabled
machine by changing the accounting entries without physically disabling
and re-enabling the machine.  Beth cried on my shoulder on Friday evening.
I was sympathetic cause she was nice, and she was traumatized by actually
witnessing the total destruction of one of her wafers.  We've discussed
this before.  It's not a trivial change, but not a complicated one either.
Do you remember why I didn't do this last time we discussed it?

Thanks,
Bill 



From vik at stanford.edu  Tue Jul 17 11:21:36 2001
From: vik at stanford.edu (Vikram Bala)
Date: Tue, 17 Jul 2001 11:21:36 -0700 (PDT)
Subject: changing snf forwarding address
Message-ID: <Pine.GSO.4.31.0107171119030.11896-100000@saga10.Stanford.EDU>


Hi:

Can you tell me how to change the e-mail address that my snf account is
forwarding to?

It is currently forwarding to vik at stanford.edu

I want it to forward to vikbala at yahoo.com

I tried editing the .qmail file, but it wouldn't let me save the edited
file.

Thanks!
Vik



From shott at snf.stanford.edu  Wed Jul 18 07:41:44 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 18 Jul 2001 07:41:44 -0700
Subject: changing snf forwarding address
References: <Pine.GSO.4.31.0107171119030.11896-100000@saga10.Stanford.EDU>
Message-ID: <3B55A028.79913ECC@snf.stanford.edu>

Vik:

I'll take care of it ... your mail should now be forwarded to the new
address.   We don't let folks adjust this themselves (yet) because we lose
consistency between the mail system and our database.  In the not-too-distant
future, however, you will be able to change these things youself ...

John


From bmurray at snf.stanford.edu  Thu Jul 19 11:16:22 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 19 Jul 2001 11:16:22 -0700 (PDT)
Subject: Schedule Today
Message-ID: <Pine.LNX.4.04.10107191111070.28520-100000@snf.stanford.edu>

John and Mike,

At 8:30am this morning, Miranda had 3 teeth extracted.  I had hoped to leave
her with her grandparents to recuperate today.  However, she doesn't feel
that well so I better take a sick day to stay with her.  I still hope to
get some work done when she's sleeping.

Feel free to call if you have any problems.  I will also check my email
throughout the day.

Thanks,
Bill





From amathur at zepton.net  Fri Jul 20 10:28:41 2001
From: amathur at zepton.net (Atul Mathur)
Date: Fri, 20 Jul 2001 10:28:41 -0700
Subject: problem in using coral remotely
Message-ID: <C8FCE8644596374D9F2C106EF6DD68BD085D61@znex01.zepton.net>

Hi:

I am a new industrial user of SNF. I have just installed remote coral on
my Windows2000 computer at my company (Zepton Networks). The Java Web
Start Application Manager shows an icon for Coral Remote (SNF). When I
try to run it, it asks me for login and password. After I enter those, I
get a message back (after some delay) saying "Can not access equipment
information!" Can you help me in solving this problem.

user name = atul

Thanks.

Atul Mathur
Zepton Networks
EMail: amathur at zepton.net
Phone: 408 573 5374


From bmurray at snf.stanford.edu  Fri Jul 20 10:35:47 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 20 Jul 2001 10:35:47 -0700 (PDT)
Subject: problem in using coral remotely
In-Reply-To: <C8FCE8644596374D9F2C106EF6DD68BD085D61@znex01.zepton.net>
Message-ID: <Pine.LNX.4.04.10107201033390.13869-100000@snf.stanford.edu>

Atul,

Coral was not designed to be used behind firewalls.  The scenario you
describe below is consistent with attempting to use Coral behind a firewall.

The Coral Development Team


On Fri, 20 Jul 2001, Atul Mathur wrote:

> Hi:
> 
> I am a new industrial user of SNF. I have just installed remote coral on
> my Windows2000 computer at my company (Zepton Networks). The Java Web
> Start Application Manager shows an icon for Coral Remote (SNF). When I
> try to run it, it asks me for login and password. After I enter those, I
> get a message back (after some delay) saying "Can not access equipment
> information!" Can you help me in solving this problem.
> 
> user name = atul
> 
> Thanks.
> 
> Atul Mathur
> Zepton Networks
> EMail: amathur at zepton.net
> Phone: 408 573 5374
> 



From bmurray at snf.stanford.edu  Sat Jul 21 12:27:21 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sat, 21 Jul 2001 12:27:21 -0700 (PDT)
Subject: Status
Message-ID: <Pine.LNX.4.04.10107211226270.28573-100000@snf.stanford.edu>

John and Mike,

I finished coding last night.  I will compile later today.  Then hope to
check all in.

Bill



From bmurray at snf.stanford.edu  Sun Jul 22 13:07:07 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sun, 22 Jul 2001 13:07:07 -0700 (PDT)
Subject: Resource Server Completed
Message-ID: <Pine.LNX.4.04.10107221254150.4891-100000@snf.stanford.edu>

John and Mike,

I have completed all the coding on the resource server and related classes
to support the new resource client.  Everything compiles under the old
makefiles and has been checked into the repository.  I have not yet tried
to compile everything under the new and improved makefiles.  I will try 
that on Monday.  

I believe my current list of tasks includes the following (in priority
order?):

1) compile everything under the new makefiles

2) tag the latest version

3) help John test the new resource module when resource client is ready

4) modify the DefaultMgrImpl to use a single configuration file

5) modify enable to support Beth and Aaron's request for "enable over"

6) add data validation to the resource module using XML Schemas

Thanks,
Bill





From shott at snf.stanford.edu  Mon Jul 23 08:24:06 2001
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 23 Jul 2001 08:24:06 -0700
Subject: Resource Server Completed
References: <Pine.LNX.4.04.10107221254150.4891-100000@snf.stanford.edu>
Message-ID: <3B5C4196.FF2C05B8@snf.stanford.edu>

Bill:

This sounds good ... and I think your priority list sounds on target.

I propose that we all get together early this afternoon to see where the
client stuff is ... particularly because we need the client to test the server
stuff.

Thanks,

John


From bmurray at snf.stanford.edu  Mon Jul 23 22:12:36 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 23 Jul 2001 22:12:36 -0700 (PDT)
Subject: New Makefiles
Message-ID: <Pine.LNX.4.04.10107232208450.24471-100000@snf.stanford.edu>

John,

Although I have not had time to do a careful check, it appears that we
got a clean make of all the new code.  However, when I attempt to
start the servers, most fail because they cannot find any of the 
persistence adapters.  My uninformed guess is that nothing in 
labnet/server/persistence made it into the server-side jar files.  
I'll take a more careful look tomorrow morning.

Thanks,
Bill 



From shott at snf.stanford.edu  Tue Jul 24 08:41:48 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 24 Jul 2001 08:41:48 -0700
Subject: Gasonics added and servers restarted ...
Message-ID: <3B5D973C.FAA8B426@snf.stanford.edu>

Len:

I think that I've added a proper equipment entry for gasonics in the equipment
table, added it to the hierarchy, and added appropriate entries for required
and optional facilities.  I've also created the gasonics and gasonics-pcs
mailing list.

Finally, I restarted the servers to make it aware of gasonics ...

Let me know if you see any problems or if I failed to do anything ...

Thanks,

John


From shott at snf.stanford.edu  Tue Jul 24 11:39:11 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 24 Jul 2001 11:39:11 -0700
Subject: Event service?
Message-ID: <3B5DC0CF.29254DDE@snf.stanford.edu>

Bill:

Len called me to say that he was getting a bunch of "could not enable
equipment" messages ... however, this was apparently from a client that had
been connected to the old servers (that is, from before the server restart).

While I was trying to see if something was wrong, he killed that client and
started a new one ... and, at about that time, experienced a bunch of the long
delays in the evnet service.  (The "I enabled it but it didn't show my name
...").  After several of the 200000 msec or so event delays, things seem to be
cleaned up.

However, this all makes me wonder whether any of our infrequent lags in the
event server may be exacerbated by "long neglected" clients that were started
under a different set of servers.

But, things seem to be OK now ...

John


From bmurray at snf.stanford.edu  Wed Jul 25 10:22:25 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 25 Jul 2001 10:22:25 -0700 (PDT)
Subject: Who is Stefani?
Message-ID: <Pine.LNX.4.04.10107251018590.27124-100000@snf.stanford.edu>

John and Mike,

In case you were wondering, stefanif is

Stefani K. Fukushima 
                                      
                          Email:
                                     Stefanif at Stanford.edu 
                          Web Page:
                                     http://www.stanford.edu/people/stefanif 
                                      
                      Organization:
                                     University 
                       Relationship:
                                     Staff 
                           Position:
                                     Buyer 
                       Department:
                                     Procurement 
                       Work Phone:
                                     (650) 725-9110 
                                Fax:
                                     (650) 723-1267 
                         Mail Code:
                                     7250 
                           Address:
                                     340 BONAIR SIDING
                                     Stanford, CA, 94305-7250 
                         SUNet IDs:
                                     Stefani.Fukushima
                                     S.Fukushima
                                     stefanif 

Bill




From bmurray at snf.stanford.edu  Thu Jul 26 10:59:21 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 26 Jul 2001 10:59:21 -0700 (PDT)
Subject: [Fwd: information on training]
In-Reply-To: <3B6043C0.DF68974F@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10107261052430.13434-100000@snf.stanford.edu>

Nancy,

That's fine.  Generally problems of this nature are emailed to coral at snf.
The behavior that Ming describes usually occurs when a member attempts to
run Coral from behind a firewall.  Coral will not run behind a firewall.
If this is not the case, Ming should email .coral-log to coral at snf.stanford.edu.

Thanks,
Bill


On Thu, 26 Jul 2001, Nancy Latta wrote:

> Gents,
> 
> I know this mail list is more system admin oriented, but I am hoping
> that I can hit someone who can take care of this one.
> 
> Please let me know if there is a more appropriate place to forward these
> kinds of problems....
> 
> 				Nancy





From mtang at snf.stanford.edu  Fri Jul 27 17:23:33 2001
From: mtang at snf.stanford.edu (Mary Tang)
Date: Fri, 27 Jul 2001 17:23:33 -0700
Subject: Remote Coral
Message-ID: <3B620605.DF102703@snf.stanford.edu>

Hello Coral Dev Team --

I've a question.  Well, actually, a quandary...

The STS etcher is one of the several tools we have which are always
booked up -- and indeed, fully reserved a week in advance.  We have some
users who are hassling our technicians about getting them reservations
more than a week in advance.  Our policy has been that we will not make
advance reservations > one week for people unless there are extenuating
circumstances -- namely, that they are coming in from out of state.

However, some local people are now saying that since they do not have
remote Coral that this comprises an "extenuating circumstance" (they
can't come to SNF to log into Coral one week to the minute in advance of
the time desired just in order to make their reservations.)

My question is whether their lack of remote Coral is lame excuse --
well, maybe not "lame", but perhaps I wonder if it is justifiable --
whether "if remote Coral were a high enough priority to them, they
should be able to make it work" or "remote Coral simply cannot be
implemented on many systems"?

Actually, there seems to be plenty of slots available between 1 and 5
am, even this weekend, so I'm tempted to say that if they were truly
dedicated to their projects, they could book this time slot...

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 shott at snf.stanford.edu  Fri Jul 27 19:35:34 2001
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 27 Jul 2001 19:35:34 -0700
Subject: Reservations and remote Coral ...
References: <3B62092B.2ACA61D3@snf.stanford.edu>
Message-ID: <3B6224F6.BB6DFFDC@snf.stanford.edu>

Mary and Nancy:

Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
so it is working for most folks on a wide variety of machines.  The one group
of people for whom remote coral doesn't work is those folks who are behind
firewalls at their place of business.  For those folks, without asking them to
compromise their computer security, they could buy a cheapo-computer and a
modem and dial-in to remote Coral through an ISP.  If that computer isn't
connected to their network, then they havent' compromised security ... I know
that at least a few of the folks who have faced the firewall problem have done
this.

It is non-trivial for us to figure out how to get remote coral to work through
a firewall ... and, to be honest, that simply can't be our highest priority.

I'm sorry to not have an answer that makes everyone happy ...

Thanks,

John


From bmurray at snf.stanford.edu  Sat Jul 28 11:21:06 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sat, 28 Jul 2001 11:21:06 -0700 (PDT)
Subject: Status
Message-ID: <Pine.LNX.4.04.10107281113030.15300-100000@snf.stanford.edu>

John,

I have done a clean build of Coral from scratch.  Everything appears to
be working well!  I have some minor changes remaining, then on to the
XML Schema validation work.

Bill 




From mtang at snf.stanford.edu  Mon Jul 30 08:28:24 2001
From: mtang at snf.stanford.edu (Mary Tang)
Date: Mon, 30 Jul 2001 08:28:24 -0700
Subject: Reservations and remote Coral ...
References: <3B62092B.2ACA61D3@snf.stanford.edu> <3B6224F6.BB6DFFDC@snf.stanford.edu>
Message-ID: <3B657D18.4212A5F5@snf.stanford.edu>

Oh, like duh, yeah, that's what I do at home -- but it hadn't occurred to me to
suggest this to anyone.  Would it be acceptable if I wrote up a quick note to this
effect and posted it on the web?  (Under a link from "Instructions for
downloading, installing, and running Remote Coral.)

Mary

John Shott wrote:

> Mary and Nancy:
>
> Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
> so it is working for most folks on a wide variety of machines.  The one group
> of people for whom remote coral doesn't work is those folks who are behind
> firewalls at their place of business.  For those folks, without asking them to
> compromise their computer security, they could buy a cheapo-computer and a
> modem and dial-in to remote Coral through an ISP.  If that computer isn't
> connected to their network, then they havent' compromised security ... I know
> that at least a few of the folks who have faced the firewall problem have done
> this.
>
> It is non-trivial for us to figure out how to get remote coral to work through
> a firewall ... and, to be honest, that simply can't be our highest priority.
>
> I'm sorry to not have an answer that makes everyone happy ...
>
> Thanks,
>
> John



From latta at snf.stanford.edu  Mon Jul 30 11:53:29 2001
From: latta at snf.stanford.edu (Nancy Latta)
Date: Mon, 30 Jul 2001 11:53:29 -0700 (PDT)
Subject: Reservations and remote Coral ...
In-Reply-To: <3B657D18.4212A5F5@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10107301151350.8616-100000@snf.stanford.edu>

Oh, yes, yes, yes!

I'd love to see a write up on how to set up a 'work-around' to a company's
firewall on the web.  I agree that the onus is on the user to get to coral
rather than the other way around.  We've done our part...

				Nancy

On Mon, 30 Jul 2001, Mary Tang wrote:

> Oh, like duh, yeah, that's what I do at home -- but it hadn't occurred to me to
> suggest this to anyone.  Would it be acceptable if I wrote up a quick note to this
> effect and posted it on the web?  (Under a link from "Instructions for
> downloading, installing, and running Remote Coral.)
> 
> Mary
> 
> John Shott wrote:
> 
> > Mary and Nancy:
> >
> > Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
> > so it is working for most folks on a wide variety of machines.  The one group
> > of people for whom remote coral doesn't work is those folks who are behind
> > firewalls at their place of business.  For those folks, without asking them to
> > compromise their computer security, they could buy a cheapo-computer and a
> > modem and dial-in to remote Coral through an ISP.  If that computer isn't
> > connected to their network, then they havent' compromised security ... I know
> > that at least a few of the folks who have faced the firewall problem have done
> > this.
> >
> > It is non-trivial for us to figure out how to get remote coral to work through
> > a firewall ... and, to be honest, that simply can't be our highest priority.
> >
> > I'm sorry to not have an answer that makes everyone happy ...
> >
> > Thanks,
> >
> > John
> 



From bmurray at snf.stanford.edu  Mon Jul 30 13:34:00 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 30 Jul 2001 13:34:00 -0700 (PDT)
Subject: Reservations and remote Coral ...
In-Reply-To: <3B657D18.4212A5F5@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10107301331110.8806-100000@snf.stanford.edu>

Mary,

That would be great!  We would really appreciate it.  John has also asked
me to add code to attempt to determine when a firewall exists and provide
a more descriptive error message than we do currently.

Thanks,
Bill

On Mon, 30 Jul 2001, Mary Tang wrote:

> Oh, like duh, yeah, that's what I do at home -- but it hadn't occurred to me to
> suggest this to anyone.  Would it be acceptable if I wrote up a quick note to this
> effect and posted it on the web?  (Under a link from "Instructions for
> downloading, installing, and running Remote Coral.)
> 
> Mary
> 
> John Shott wrote:
> 
> > Mary and Nancy:
> >
> > Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
> > so it is working for most folks on a wide variety of machines.  The one group
> > of people for whom remote coral doesn't work is those folks who are behind
> > firewalls at their place of business.  For those folks, without asking them to
> > compromise their computer security, they could buy a cheapo-computer and a
> > modem and dial-in to remote Coral through an ISP.  If that computer isn't
> > connected to their network, then they havent' compromised security ... I know
> > that at least a few of the folks who have faced the firewall problem have done
> > this.
> >
> > It is non-trivial for us to figure out how to get remote coral to work through
> > a firewall ... and, to be honest, that simply can't be our highest priority.
> >
> > I'm sorry to not have an answer that makes everyone happy ...
> >
> > Thanks,
> >
> > John
> 



From mtang at snf.stanford.edu  Mon Jul 30 17:36:09 2001
From: mtang at snf.stanford.edu (Mary Tang)
Date: Mon, 30 Jul 2001 17:36:09 -0700
Subject: Reservations and remote Coral ...
References: <3B62092B.2ACA61D3@snf.stanford.edu> <3B6224F6.BB6DFFDC@snf.stanford.edu>
Message-ID: <3B65FD79.19B67E6E@snf.stanford.edu>

Wups!

I should have known -- John's writeup (which I imported to the website) already
explains this very nicely.  But I modified the relevant pages so perhaps this is
more obvious, even to airheads like me.

http://snf/Labmembers/RemoteCoralTSGuide.html
http://snf/Labmembers/RemoteCoralHowTo.html

Mary

John Shott wrote:

> Mary and Nancy:
>
> Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
> so it is working for most folks on a wide variety of machines.  The one group
> of people for whom remote coral doesn't work is those folks who are behind
> firewalls at their place of business.  For those folks, without asking them to
> compromise their computer security, they could buy a cheapo-computer and a
> modem and dial-in to remote Coral through an ISP.  If that computer isn't
> connected to their network, then they havent' compromised security ... I know
> that at least a few of the folks who have faced the firewall problem have done
> this.
>
> It is non-trivial for us to figure out how to get remote coral to work through
> a firewall ... and, to be honest, that simply can't be our highest priority.
>
> I'm sorry to not have an answer that makes everyone happy ...
>
> Thanks,
>
> John

--
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 bmurray at snf.stanford.edu  Mon Jul 30 17:44:08 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 30 Jul 2001 17:44:08 -0700 (PDT)
Subject: Reservations and remote Coral ...
In-Reply-To: <3B65FD79.19B67E6E@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10107301742060.8806-100000@snf.stanford.edu>

I take exception to the use of the word "airhead" with respect to Mary
Tang!  Cease and desist immediately!

Thanks,
Bill



On Mon, 30 Jul 2001, Mary Tang wrote:

> Wups!
> 
> I should have known -- John's writeup (which I imported to the website) already
> explains this very nicely.  But I modified the relevant pages so perhaps this is
> more obvious, even to airheads like me.
> 
> http://snf/Labmembers/RemoteCoralTSGuide.html
> http://snf/Labmembers/RemoteCoralHowTo.html
> 
> Mary
> 
> John Shott wrote:
> 
> > Mary and Nancy:
> >
> > Hmm ... last time I looked, over 200 people had set reomte passwords for Coral
> > so it is working for most folks on a wide variety of machines.  The one group
> > of people for whom remote coral doesn't work is those folks who are behind
> > firewalls at their place of business.  For those folks, without asking them to
> > compromise their computer security, they could buy a cheapo-computer and a
> > modem and dial-in to remote Coral through an ISP.  If that computer isn't
> > connected to their network, then they havent' compromised security ... I know
> > that at least a few of the folks who have faced the firewall problem have done
> > this.
> >
> > It is non-trivial for us to figure out how to get remote coral to work through
> > a firewall ... and, to be honest, that simply can't be our highest priority.
> >
> > I'm sorry to not have an answer that makes everyone happy ...
> >
> > Thanks,
> >
> > John
> 
> --
> 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 shott at snf.stanford.edu  Tue Jul 31 18:11:28 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 31 Jul 2001 18:11:28 -0700
Subject: Size of /var/adm/wtmpx files ....
Message-ID: <3B675740.C85B5E92@snf.stanford.edu>

Bill and Mike:

Boy has /var/adm/wtmpx gotten to be big ... I manually truncated it and
compressed the previous result on July 6, I think, and it has grown to
1.4GB!!! It should truncate and compress it overnight (since it is a monthly
rollover tonight), so it will be intersting to see how large the compressed
version is.  Also, /var/adm/wtmp is about 130MB as well.

I don't know the details of exactly what these files contain, but they appear
to get something added everytime someone logs in or logs out (and judging from
the size of them) must also put something in everytim a smart card is
inserted/extracted.

Clearly, my thought that we could truncate and compress once a month was not a
good idea ... I'd say we are going to have to do this weekly, at most ...

I should probably do some playing around to see how quickly things grow under
various login/logout/card insert/card extract conditions (probably on a
weekend morning where there is no other activity) ... but gee these files are
big.


My guess is that these various wtmp, wtmpx, utmp, utmpx files being so large
is an explanation of why uptime and "w" are behaving strangely:  On sunray all
of the entries for "tty" sunray have funny numbers ... Idle times of 385 days,
for example, and if you say uptime, it doesn't seem to know when it was last
rebooted.

When we have a break in the action, we should probably explore this with Sun
... either we have something going wrong or we have set a new world record for
number of login/logouts per day that has blown their wtmp/wtmpx strategy out
of the water.

See you all tomorrow,

John