From mbell at snf.stanford.edu  Thu Nov  2 10:54:31 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Thu, 02 Nov 2000 10:54:31 -0800
Subject: Connectivity 
Message-ID: <3A01B867.14A5E82A@snf.stanford.edu>

Coral team -

Viagra is now setup to connect outside our firewall, but there is a
problem getting through the "building switch".  Since I don't have
access to this Jason is checking into the problem.  I'll follow the
problem closely to ensure resolution.

Security and bacukups for Rosen is my focus for today.

Mike


From ken.wilcox at perfectorder.com  Thu Nov  2 11:20:22 2000
From: ken.wilcox at perfectorder.com (Ken Wilcox)
Date: Thu, 02 Nov 2000 14:20:22 -0500
Subject: Coral Software
Message-ID: <3A01BE76.606E742F@perfectorder.com>

Hello, my name is Ken Wilcox and I am the Sun rep. for Penn State Univ.
I've been working with a group there in the Materials Research Labs that
are interested in this software to work in their Nonfab. facility. I
don't know much about it, but I told them I would look into it and help
them. 

They were thinking that Sun helped develop this software, while I was
thinking they helped with desigining the environment that runs the
software. I said I'd help clarify those issues as well. 

Thanks in advance for any information you can give.

-Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.wilcox.vcf
Type: text/x-vcard
Size: 390 bytes
Desc: Card for Ken Wilcox
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20001102/37c16c85/attachment.vcf>

From shott at snf.stanford.edu  Thu Nov  2 11:38:35 2000
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 02 Nov 2000 11:38:35 -0800
Subject: [Fwd: SunSolve Document]
Message-ID: <3A01C2BB.30CE9B0C@snf.stanford.edu>

SunRay FAQ from Sun that contains some useful information ....

John
-------------- next part --------------
An embedded message was scrubbed...
From: Sandra Jones <stjones at ebay.sun.com>
Subject: SunSolve Document
Date: Thu, 13 Jan 2000 14:18:10 -0800 (PST)
Size: 14408
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20001102/b31bb603/attachment.mht>

From shott at snf.stanford.edu  Thu Nov  2 11:50:43 2000
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 02 Nov 2000 11:50:43 -0800
Subject: Coral Software
References: <3A01BE76.606E742F@perfectorder.com>
Message-ID: <3A01C593.6AA83B61@snf.stanford.edu>

Ken:

You are correct ... our Coral application software has been developed by us
(in Java) and uses a lot of the Sun Java infrastructure support including
CORBA for client/server and server/server communications, Swing for the GUI
stuff, JDBC for database connectivity, etc. We do run it on top of a SunRay
server and have something like 25-30 SunRay 1 Network appliances distributed
throughout our lab.  In a lab like ours (that is probably pretty similar to
the lab at PSU) the mobility offered by the smart cards and the SunRay hot
desk technology is a big win!!!! In a large lab with lots of pieces of
equipment, folks are at one machine for a while, move to another part of the
lab, etc. ...

More recently, we are on the verge of deploying our application clients
outside of the lab using the Beta Release of Java Web Start 1.0 ... another
Sun offering.

So, our application and environment is a bit of a showcase for Sun technology
... but Sun really hasn't been directly involved in any of our application
developemnt.

We are in the process of trying to identify a configuration of hardware and
software that might be suitable for deployment of our applications into other
university labs because we think that there are a number of similar labs that
could benefit from using this package.  Although people wouldn't have to
deploy Sunrays ... it seems to be a nice option.

I hope this helps,

John


From mbell at snf.stanford.edu  Thu Nov  2 15:39:35 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Thu, 02 Nov 2000 15:39:35 -0800
Subject: the problem with viagra
Message-ID: <3A01FB37.D092C0B2@snf.stanford.edu>

Turns out it was actually an issue with the default router which I
switched to the standard for 171 segment machines. I also added a
secondary route statement to allow it to see the development segment.
Bill you should be able to ping it from home. I'll unplug it from the
"outside" tonight before I go home since it may not be locked down yet.

Mike


From bmurray at snf.stanford.edu  Thu Nov  2 16:55:56 2000
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 2 Nov 2000 16:55:56 -0800 (PST)
Subject: the problem with viagra
In-Reply-To: <3A01FB37.D092C0B2@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10011021655420.14000-100000@snf.stanford.edu>

Mike,

I can see it fine now.

Bill

On Thu, 2 Nov 2000, Mike Bell wrote:

> Turns out it was actually an issue with the default router which I
> switched to the standard for 171 segment machines. I also added a
> secondary route statement to allow it to see the development segment.
> Bill you should be able to ping it from home. I'll unplug it from the
> "outside" tonight before I go home since it may not be locked down yet.
> 
> Mike
> 



From shott at snf.stanford.edu  Thu Nov  2 23:01:47 2000
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 02 Nov 2000 23:01:47 -0800
Subject: dtlogin update ...
Message-ID: <3A0262DB.7C0FFF82@snf.stanford.edu>

Bill and Mike:

I did a check of sunsolve.sun.com and found that there is a brand new patch
for dtlogin (effective 10/31) that apparently fixed a problem of dtlogin
hanging under high loads.  So ... I figured that it couldn't hurt to install
it and then restarted dtlogin (/etc/init.d/dtlogin/stop
/etc/init.d/dtlogin/start) .... all of a sudden dtlogin drops from 162 MB to
about 5 MB ...

When I got up into the machine room, I found that there were a number of
messages that /tmp was full ... if you look in /tmp you will se a number (50
or so) things that look like dtdb files that I'll bet are symptoms of
problems.

However, there are also in /tmp/SUNWut/config several directories name idle,
tokens, etc .... I think that these are ones in the past that I had noticed
seemed to be growing with a large number of files.  Each one isn't so big, but
I'm suspicious that, for some reason, these things aren't getting cleaned up
properly.

So ... while I'm not sure that the new dtlogin patch has fixed anything, I do
believe that the symptoms will go away for atleast a few days.  However, I
think that it would be good to see if the files in /tmp/SUNWut/* begin to grow
in number.  At the moment (by doing a ls -l | wc in each directory) I find
that the number of files is something like 27 in display and itokens (which, I
suspect is the number of sunrays and may not grow.  However, idle has
something like 46 files (I think 2 per idle Sunray ... and there is virtually
no activity now).  I've got a hunch that some of the stuff in the tokens
and/or config directories may begin to grow over time ... but we'll see.

Well, back to NNUN data extraction ...

John


From mbell at snf.stanford.edu  Mon Nov  6 11:48:32 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Mon, 06 Nov 2000 11:48:32 -0800
Subject: Informix options - 
Message-ID: <3A070B10.E44A18EE@snf.stanford.edu>

John and Bill,

I spoke with Informix and the cost is $0 if we qualify for the grant. 
We also get 2 free classes.  After the first year the cost is $1500 for
support and classes are 50% of list.  Classes tend to run about $2,100
each.  They have a lot of classes in Menlo Park, not that we really need
one to get started, but the grant requires it.  They are checking on the
cost of hardcopy documentation as well as the recommended backup
software.

The only fly in the ointment is that after 5 years we might have to buy
the licenses and they didn't have the costs ready for me on that. 

Take a look at the website below and tell me what products we want.  I
downloaded the application and can get it ready (for John's review) if
we still want to go with them. 


Thanks,

Mike 

http://www.informix.com/informix/grant/benefits/offering.htm#Packages &
Solutions


From mbell at snf.stanford.edu  Mon Nov  6 15:58:09 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Mon, 06 Nov 2000 15:58:09 -0800
Subject: Wonderwall
Message-ID: <3A074591.4A4B8CE0@snf.stanford.edu>

Coral Team -

Iona's firewall product is only sold with their ORB product.  We get it
for 75% off which makes the cost about $1400 for the first year
including support at $650 per year.

It doesn't support Linux yet.  It doesn't support other ORBs, the sales
person thinks. Should I research this product anymore?

Mike


From shott at snf.stanford.edu  Mon Nov  6 16:47:38 2000
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 06 Nov 2000 16:47:38 -0800
Subject: Wonderwall
References: <3A074591.4A4B8CE0@snf.stanford.edu>
Message-ID: <3A07512A.4EE73589@snf.stanford.edu>

Mike:

I would suggest that we hold off on wonderwall for the time being ... I think
that our current public rosen approach doesn't need it and I'm convinced that
an open source/public domain firweall that lets through CORBA traffic will be
available soon.

Does this differ from your thinking, Bill?

Thanks,

John


From mbell at snf.stanford.edu  Tue Nov  7 12:27:35 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Tue, 07 Nov 2000 12:27:35 -0800
Subject: [Fwd: snf web pages]
Message-ID: <3A0865B7.CCCE93F8@snf.stanford.edu>

Bill and John,

I talked to Jason and he is willing to continue to setup logons and
provide some support for the Shades cluster.  He indicated it would be
OK to use his name instead of Joe's on the webpage.  This sounds good at
least for the short term. Do you both agree?

Who do I contact about changing the webpage?

Thanks,

Mike
-------------- next part --------------
An embedded message was scrubbed...
From: Jason Conroy <jconroy at teargarden.Stanford.EDU>
Subject: snf web pages
Date: Mon, 6 Nov 2000 12:23:49 -0800 (PST)
Size: 1422
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20001107/56f59d0e/attachment.mht>

From mbell at snf.stanford.edu  Fri Nov 10 18:29:00 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Fri, 10 Nov 2000 18:29:00 -0800
Subject: New IPs
Message-ID: <3A0CAEEC.E325BC8F@snf.stanford.edu>

sunstar.stanford.edu    171.64.101.124

reef.stanford.edu	171.64.101.171


From mbell at snf.stanford.edu  Wed Nov 15 12:02:36 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Wed, 15 Nov 2000 12:02:36 -0800
Subject: Restore of database test
Message-ID: <3A12EBDC.985D7087@snf.stanford.edu>

One of the things on my list is to do a full restore of the database to
Bopeep.  This will give us fresh data in the test system and verify that
our backups are functional - important now that we have a bit more
exposure. The best candidate would be the 11/09/00 full backup with
Oracle down. We may also want to do a test  using a backup set with
Oracle up and see if it still restores and is functional.  I'd like to
do both of these AFTER Bill finishes any mods he is working on to get
CORAL Remote running.

Long term the Oracle Agent needs to be loaded on Rosen, of course.

I did get our license upgraded for that also, but I need to download all
the modules off Sun's website and install a new version on Viagra, and
Rosen.  The new version will get us the ability to backup the Linux
servers as well.

Misc other backup issues -

I need a test Mac to load the Veritas backup agent so I can get the Macs
off veritas.  Can I use the Mac backup machine?

I need a list of all the PCs and Macs that we want to back up.  Should I
do an email to staff asking who has a machine we need to backup?  What
list would be the best to use?  It will take sometime to get this setup
correctly since it may involve changing where applications store their
data and repartitioning there hard drives (I have Partition Magic to do
this. John, let me know when you want to do yours. I know you've been
busy.)  I will schedule one or more a day to knock this out.

Mike


From shott at snf.stanford.edu  Fri Nov 24 12:36:30 2000
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 24 Nov 2000 12:36:30 -0800
Subject: Conversion from idltojava to idlj ...
Message-ID: <3A1ED14E.8E3AEE52@snf.stanford.edu>

Bill and Mike:

I'm in the process of trying to convert from idltojava to idlj as there is
enough time to think ...

To do this, I've made a copy of ~bmurray/labnet in ~shott/labnet1.3 ... in
other words, ~shott/labnet1.3/labnet is the top directory in my experimental
source tree.  Note: I know that you have a bunch of stuff that isn't checked
in, Bill, so I have all of that in my source tree. As you'll see, I've made a
number of changes to a variety of files ... but I'm guessing that they are
largely non-overlapping and non-conflicting.  My initial thought is that we
wait to check in your files normally when you are happy with them and then,
once we think that the idlj stuff is OK, we check-in the changes that I've
made. (Of course, that would require manually updating my files with any
changes that you make from here on out ...).

So, I'm going to try to keep a running log of what I've done:

1. I've made significant changes to labnet/etc/Makefile (specifically to the
stuff that converts idl into java. The most significant change is that the old
idltojava allowed one to define a package that everything was a part of (and
we used that flag to define everything as a part of the package labnet.idl so
that things in package Auth actually became labnet.idl.Auth.*.  However, the
file stuff in Base.idl doesn't really define a package ... but the old -p flag
made Timestamp, labnet.idl.Timestamp, etc.

idlj doesn't have the -p (package flag) ... it has the -pkgPrefix flag. This
works for the things that are apart of a package such as Auth ... we could
define a "-pkgPrefix Auth labnet.idl" that makes everything in Auth a member
of labnet.idl.Auth.*.  However, all of the stuff in Base.idl gets "lost"
because it isn't part of a package.  To get around this, I modified each of
the *.idl files so that they look like:
module labnet {
	module idl {
		Original idl file goes here ...
	}; // End of idl module
}; // End of labnet module
Actually, I put the "module labnet {" beyond any "#include" stuff because each
of the included files (either Base.idl or Admin.idl) already have been defined
to be a part of the labnet.idl package ...

In that way, even though it is a bit brute forceish, everything seems to
compile OK.  Well, actaully, in Resource.idl, there were three forward
declarations of interfaces that whose definition was commented out:
ConfigurationManager, RulesManager, and DesktopManager.  idlj apparently
doesn't allow any forward declarations that are undefined ... so I simply
commented out these three forward declarations.

So, the Makefile changes now allow things to compile without any errors and
without any warnings about deprecated methods ...

Oh yes, it does complain about the use of the "Factory" interface .... I
changed that to the Laboratory interface and also changed places in the entire
source tree (there were only a handful) that make a reference to Factory or
getFactory and changed them to Laboratory and getLaboratory, respectively
(except, there is something called ticketFactory that I didn't change ...)

2. Now I began to look at the differences in the *.java files that are
generated.  As near as I can tell, an interface named "Interface" used to
generate 7 *.java files and now generates 6.
Four of them appear quite similar:
	Interface.java
	InterfaceHelper.java
	InterfaceHolder.java
	_InferfaceStub.java

The old _InterfaceOperations.java has become InterfaceOperations.java
and the old _InterfaceTie.java and _InterfaceImplBase.java appear to have been
combined into a single file called: Interface_Tie.java.

3. So, the next step is to see if I can get things running by mechanically
changing occurrences of _InterfaceOperations to InterfaceOperations and
_InterfaceTie to Interface_Tie.  To find these occurences, I went to
~shott/labnet1.3/labnet and issued the command:
	gitrgrep _[A-Z][a-zA-Z]*Tie '*.java' > Tie.txt
	gitrgrep _[A-Z][a-zA-Z]*Operations '*.java' > Operations.txt

It appears as if there are only about 15-20 occurrences of each. For example,
most of the managers such as AccountingManagerImpl.java have a line that
reads:
implements labnet.idl.Accounting._AccountingManagerOperations {

Similarly, Accounting Server.java has a line that reads:
this.mgr = new _AccountingManagerTie(this.impl)

So, I figured I would see what happens when I simply change
_InterfaceOperations to InterfaceOperations and _InterfaceTie to Interface_Tie
in these files.

4. In order to compile this stuff, it appears as if I need an installed
idl.jar file in /home/labnet/lib ... to do that, I made a copy of the original
idl.jar file and called it idl.jar and then "make install idl".

5. Doing a "make distclean" in labnet/idl and then a "make distclean" in
labnet (all in ~shott/labnet1.3) ... in general seemed to be doing most things
and compiling OK.  There were a series of errors related to calling
AthMgr.authenticate(name, password) ... it looks as if Bill has changed the
idl recently to do authenticate(name) and remoteAuth(name, password).

So, at this point, I'm probably going to put things on hold until Bill gets
back ... because I'm about to get out of my depth.

However, in summary, I've got a duplicate version of what Bill has in
~bmurray/labnet stored in ~shott/labnet1.3/labnet that is, I think, close to
working with the new idlj compiler ...

That's it for now ...

Thanks,

John

p.s. I've moved /home/labnet/lib/idl.jar.orig back as /home/labnet/lib/idl.jar
and moved the new one to /home/labnet/lib/idl.jar.idlj


From shott at snf.stanford.edu  Sat Nov 25 11:11:28 2000
From: shott at snf.stanford.edu (John Shott)
Date: Sat, 25 Nov 2000 11:11:28 -0800
Subject: idlj conversion update ...
Message-ID: <3A200EE0.D51DE4C6@snf.stanford.edu>

Bill and Mike:

I've done a bit more fiddling with my version of Bill's latest version ... my
stuff is in ~shott/labnet1.3/labnet ...

1. I found a number of cases where there was a call to authenticate(username,
password) ... If I am reading things correctly, this has been replaced
everywhere by authenticate(username) ... assuming that the user has already
authenticated themselves when they logged in to sunray if they are local
users. If they are remote, they call (I think) remoteAuth(username, password)
...  The files where I made changes are: (note, some of these may no longer be
used and may be vestiges of stuff that Troy did ...)

main/Labnet.java
client/DefaultLabApp.java
auth/client/AuthClient.java
auth/server/AuthManagerImpl.java
resource/client/ObjectClient.java
resource/client/MemberRelationRequest.java

2. It appears that admin/server/AdminManagerImpl.java throws an
InvalidTicketSignal and an NotAuthroizedSignal for its "shutdown" method ...
but the idl appears to be a oneway with no excpetions.  As a result, I
commented out the "throws" part in the above file.

Now, I'm going to do a make distclean in ~shott/labnet1.3/labnet and then in
idl and see if I get a clean compile ...

Hooray ... I think that I'm getting a clean comile.  The only warning that I
get is a deprecation warning in util/EventSubscriberImpl.java that complains
about the extract.Principal() method from org.omg.CORBA.Any.  My guess is that
we've gotten this warning for quite a while.  It appears to me, however, that
converting to ildj from idltojava has eliminated all of the deprecated methods
that used to be generated by idltojava.

So, where do we stand:

1. I've changed a lot of files ... but mostly in pretty trivial ways.  I think
that Bill's files (including all of his unchecked in stuff) and mine are
consistent except for the changes I've listed above.

2. I, of course, haven't yet tested whether this stuff actually runs ... I
suppose that I could do that and then switch back to the stuff in
/home/labnet/.prod-install (with, possibly, the need to make sure that I have
the appropriate old idl.jar file in /home/labnet/lib.

3. If it is a nuisance to incorporate this stuff now, I think that I can
convert the whole mess based on whatever your latest version looks like once
the remote stuff is done in a couple of hours.  In summary, the main things
that I have done are:

Modify etc/Makefile for idlj support

Add module labnet { module { idl ... to idl/*.idl files

Change instances of Factory (and getFactory) to Laboratory and getLaboratory
in idl.  Also a handful of changes in filenames or specific files that
currently include Factory

Change references to _InterfaceOperations to InterfaceOperations in ~15 files.

Change references to _InterfaceTie to Interface_Tie in ~15 files

Change authenticate(name, password) to authenticate(name) in ~10 files

I may have forgotten a couple of things ... but I think that this is it.

I've temporarily done a prod-install of the idlj version ... I think that it
is doing what I remember seeing with Bill's latest version:

In /var/log/labnet/athmgr.log it reports:
Unable to construct an encryption object.
java.security.InvalidKey Exception: Wrong algorithm: DES required ...

Also, the "Remote Password" option in the client appears to do nothing and
reports an error:
java.lang.NullPointerException at: labnet.main.PasswordAction.actionPerformed
(PasswordAction.java:75)

My guess is that these are the things that you were working on when you left,
Bill.

So, there we are ... I've re-installed the version in
/home/labnet/.prod-install so that eveything should be running for normal
users.

Talk to you later,

John


From mbell at snf.stanford.edu  Tue Nov 28 10:17:30 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Tue, 28 Nov 2000 10:17:30 -0800
Subject: sunray crash
Message-ID: <3A23F6B9.1DCC180F@snf.stanford.edu>

Bill

The prtdiag command didn't show any problems. Give me any information
that will be helpful and I can call Sun and harass them.

Mike


From mbell at snf.stanford.edu  Tue Nov 28 15:55:07 2000
From: mbell at snf.stanford.edu (Mike Bell)
Date: Tue, 28 Nov 2000 15:55:07 -0800
Subject: [Fwd: CIS partial power outage]
Message-ID: <3A2445DB.BB49CA28@snf.stanford.edu>

John & Bill,

Turns out SNF is not being backed up.  If we get Jason to do it, it's
one less thing we have to do. If we do it ourselves we can verify that
the backup is timely and correct ourselves.  I can go either way on this
one.  I'm not sure if Jason is exactly volunteering for this, although
he has always been very helpful in the past.

Mike
-------------- next part --------------
An embedded message was scrubbed...
From: Jason Conroy <jconroy at teargarden.Stanford.EDU>
Subject: Re: CIS partial power outage
Date: Tue, 28 Nov 2000 14:37:11 -0800 (PST)
Size: 2035
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20001128/132ea952/attachment.mht>

From hopcroft at snf.stanford.edu  Tue Nov 28 23:12:57 2000
From: hopcroft at snf.stanford.edu (Matt Hopcroft)
Date: Tue, 28 Nov 2000 23:12:57 -0800 (PST)
Subject: Tuesday Night 28NOV
Message-ID: <Pine.LNX.4.04.10011282310350.12284-100000@snf.stanford.edu>


FYI: coral is not operational tonight, Tuesday 28NOV. The error message is
"Cannot access equipment information!"


Matt Hopcroft
hopcroft at snf.stanford.edu