From bmurray at snf.stanford.edu  Tue Jun  4 17:05:48 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 4 Jun 2002 17:05:48 -0700 (PDT)
Subject: dektak interlock problem
Message-ID: <Pine.LNX.4.04.10206041703320.24192-100000@snf.stanford.edu>

Len,

We appear to be having problems with the dektak interlock box.  It started
yesterday evening and is happening again now.   I've included the error
message from the hardware manager log.  The return value is out of range.

2002-06-04 16:56:54 ->
Instuction count: 1
Cardid: 1
Evenport: 768
Oddport: 769
Channel: 21
Ok: 1
Command type: 1
Command: 0
Delay: 0
SdOverload: 0
RdOverload: 0
AdcDone: 1
Busy: 0
ReturnValue: -97

2002-06-04 16:56:54 - dektak: Enable failed.  Return value exceeds limits.

Bill



From bmurray at snf.stanford.edu  Thu Jun  6 19:44:38 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 6 Jun 2002 19:44:38 -0700 (PDT)
Subject: dektak interlock problem (fwd)
Message-ID: <Pine.LNX.4.04.10206061944130.21131-100000@snf.stanford.edu>

John,

Any preference?

Bill

---------- Forwarded message ----------
Date: Thu, 06 Jun 2002 15:24:06 -0700
From: Len Booth <booth at snf.stanford.edu>
To: Bill Murray <bmurray at snf.stanford.edu>
Subject: Re: dektak interlock problem

Bill -
	I looked at the Dektak interlock this afternoon.
There is no interlock box on the Dektak at all.  There is
a phone cord for an interlock box, but I'd say it has
not been used in a long time.  I don't know what could
have changed recently, to cause errors when a user enables.
Apparently users have been told for a long time to use 
CORAL to enable the Dektak (even though there is no box)
and they previously did not get an error.
What would you like to do?
			Len



From bmurray at snf.stanford.edu  Fri Jun  7 10:55:55 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 7 Jun 2002 10:55:55 -0700 (PDT)
Subject: dektak interlock problem
In-Reply-To: <3CFFE106.C6B1DE87@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10206071050260.25815-100000@snf.stanford.edu>

Len,

I have changed the database to indicate that the dektak is not interlocked.
When a member attempts to enable/disable the equipment, the equipment
manager will do a logical enable/disable without doing a physical enable/
disable on the Walker box.  To avoid any confusion, I have also removed
the cardnumber and channel for the dektak from the database.  For your
reference, the phone cord behind the detak is connected to cardnumber 1
and channel 21.  As soon as I complete the change from wbgaassol to
wbsolvent, I will reboot the servers, and these changes will take effect.

Thanks,
Bill

On Thu, 6 Jun 2002, Len Booth wrote:

> Bill -
> 	I looked at the Dektak interlock this afternoon.
> There is no interlock box on the Dektak at all.  There is
> a phone cord for an interlock box, but I'd say it has
> not been used in a long time.  I don't know what could
> have changed recently, to cause errors when a user enables.
> Apparently users have been told for a long time to use 
> CORAL to enable the Dektak (even though there is no box)
> and they previously did not get an error.
> What would you like to do?
> 			Len
> 




From bmurray at snf.stanford.edu  Fri Jun  7 11:56:20 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 7 Jun 2002 11:56:20 -0700 (PDT)
Subject: Equipment Name Changes
Message-ID: <Pine.LNX.4.04.10206071042130.25815-100000@snf.stanford.edu>

John,

I've made the wbsolvent changes and tested all.  Looks good.

Here's the list of tables with the column names which required changes
when I changed an equipment name:

	Table			Attribute

	equipment		name
	eq_affiliation		name
	current_eq		item
	uses			master, slave
	requires		master, slave
	eq_activity		item
	eq_history		item
	problems		item
	shutdowns		item
	comments		item

	reservation		item
	
	qualify			item
	adjustment		item
	
	activity		item
	activity_sum		item
	equipment_sum		item
	
	eq_rate			name
	res_rate		name
	
	staff_activity		item
	training		item

Bill

	
	
	






From bmurray at snf.stanford.edu  Fri Jun  7 13:47:36 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 7 Jun 2002 13:47:36 -0700 (PDT)
Subject: [Fwd: Wet Bench CORAL improvements] (fwd)
Message-ID: <Pine.LNX.4.04.10206071345050.25815-100000@snf.stanford.edu>

John,

Have you made these changes?  At the time I made the other changes, I wasn't
aware that this might need to be done also.  Would you like me to change
cardnumber to 0, channel to 12, and interlocked to 1 for wbsolvent?  I will
need to restart the servers for this to take effect.

Thanks,
Bill

---------- Forwarded message ----------
Date: Thu, 06 Jun 2002 13:31:06 -0700
From: Uli Thumser <uli at snf.stanford.edu>
To: bmurray <bmurray at Stanford.EDU>
Subject: [Fwd: Wet Bench CORAL improvements]



-------- Original Message --------
Subject: Wet Bench CORAL improvements
Date: Fri, 31 May 2002 13:31:13 -0700
From: Len Booth <booth at snf.stanford.edu>
To: shott at snf.stanford.edu
CC: uli at snf.stanford.edu

John -
        I have installed a new interlock box
on the WBgaassol solvent bench (as per Uli).
Rack 13 had no unused CORAL receptacles, but
since the Spectrum is unused, I ran the phone
cord for the WBgaassol to the port for Spectrum.
The Walker port should be  Card# 0, Channel# 12

Uli & Mahnaz have agreed that the name for this
bench should be changed from wbgaassol to wbsolvent

Could you please make the CORAL table entries
that are needed to change the name spectrum
to wbsolvent?  

If you can let me know when you have made the
changes, I'll double check that everything is
working as expected.
			thanks,
			Len



From bmurray at snf.stanford.edu  Fri Jun  7 14:28:18 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 7 Jun 2002 14:28:18 -0700 (PDT)
Subject: wbsolvent interlock
Message-ID: <Pine.LNX.4.04.10206071425040.28312-100000@snf.stanford.edu>

Len,

As we discussed, I have modified the equipment table so that the wbsolvent
is now interlocked using the phone line that originally went to the 
spectrum.  That is card 0 and channel 12.  I have also changed the table
so that the spectrum is no longer interlocked.  I have restarted the servers
so these changes should be in effect now.  Could please confirm that 
everything is working properly?

Thanks,
Bill




From shott at snf.stanford.edu  Mon Jun 10 15:11:59 2002
From: shott at snf.stanford.edu (John Shott)
Date: Mon, 10 Jun 2002 15:11:59 -0700
Subject: StarOffice on atu?
Message-ID: <3D05242F.DB7CACCD@snf.stanford.edu>

Mike and Bill:

I'm in the process of trying to install StarOffice 6.0 on atu ... StarOffice
only runs on Solaris 7 and newer (well, it runs on Linux and windows too ...
but not on Solaris 2.6).

I think that I've got the server part installed, but need to have my home
directory mounted (it looks like it assumes that we will all have /home/Devel/
mounted.  However, I notice that there is /home/Devel/oracle (that isn't
mounted from elsewhere) that contains some of the log files from the oracle
install on atu.

On rosen and friends, there is /home/Devel/oracle that is the home directory
for the rosen oracle install.  Rather than blindly mounting /home/Devel onto
atu ... and, I think, overwriting this stuff ... I figured I'd check it out.

Thanks,

John

p.s. The reason that I'm interested in this is that StarOffice now has a JDBC
interface to databases.  It also, although I haven't yet seen it, has a Java
API.  I'm looking at this because it may be the "poor man's" Actuate ...


From bmurray at snf.stanford.edu  Mon Jun 17 23:10:36 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 17 Jun 2002 23:10:36 -0700 (PDT)
Subject: Coral on atu (Status)
Message-ID: <Pine.LNX.4.04.10206172303210.7608-100000@snf.stanford.edu>

John and Mike,

I have loaded the Coral tables on atu with data that I exported from 
the Coral tables on bopeep.  I have gotten a clean compile and install
of the Coral code on atu.  When I attempt to start the servers, the
admin manager attempt to connect to Oracle is refused.  This may be
related to the jdbc driver that I'm using ( I just copied the one from
rosen ) or it may be related to the Oracle listener (or the port I'm
attempting to use).  I also need to get an httpd server running on atu
so the other servers can get access to the AdminServerIOR.

I think we're very close to having Coral running on atu.

Bill 





From shott at snf.stanford.edu  Tue Jun 18 07:53:09 2002
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 18 Jun 2002 07:53:09 -0700
Subject: Coral on atu (Status)
References: <Pine.LNX.4.04.10206172303210.7608-100000@snf.stanford.edu>
Message-ID: <3D0F4955.9A321F78@snf.stanford.edu>

Bill:

Thanks for the Coral update ... I'm guessing that the old JDBC driver isn't
going to work ... I recall being at the Oracle site at some point and recall
seeing that there is a different JDBC driver for each version of oracle.  If I
can remember login and password of that site, I may go to see if I can find
the appropriate driver for 9i.

Talk to you later,

John


From bmurray at snf.stanford.edu  Tue Jun 18 08:57:31 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 18 Jun 2002 08:57:31 -0700 (PDT)
Subject: UCB & Coral
Message-ID: <Pine.LNX.4.04.10206180855090.12586-100000@snf.stanford.edu>

John and Mike,

Here's my response to a message from Ferenc at UCB.  His message at the
bottom provides some clues to their approach with Coral.

Bill

My reply:

Ferenc,

You are correct.  There were two major issues to address in modifying the
persistence layer to push all transactions, locking, and caching to the
underlying database.  Connection pools would be required, and the persistence
layer would need to be modified to work correctly with these objects.  

The other issue was related to locking and caching.  I followed the
Object Data Management Group (ODMG) specification for persistence of
object-oriented programming language objects in databases: the Object
Data Standard ODMG 2.0.  The model supports read, write, and upgrade
locks that follow the same semantics as those defined in the OMG
Concurrency Control Service.  These locks are similar to those used
in relational products but do varying in significant ways.  Although
we could attempt to simulate these locks using such things as the
"transaction isolation level" and "select for update", there are still
some difficult problems.  For example, in our application servers we
explicitly request upgrade locks on objects.  Since these objects may
already be cached and in-use by other threads with read locks, it may
be too late to attempt a "select for update" from the underlying database.
I don't believe these problems are insurmountable, just tricky and time-
consuming to address.

Good luck with your presentation to Katalin.  Let me know how it goes
and what you decide.

Thanks,
Bill

On Mon, 17 Jun 2002, Ferenc Varju wrote:

> Hi Bill,
> 
> I am working on the presentation for Katalin, and I realized that I will
> need to handle multiple conections in my program as well.  I decided to
> create the connection pool object you mentioned.  I already have a skeleton
> for it and I think that I will be ready with it in a a few days.  What was
> the other issue that you were concerned about?  I am sorry, but I forgot it.
> I might take care of it as well.
> 
> Regards,
> Ferenc
> 



From shott at snf.stanford.edu  Thu Jun 20 08:34:21 2002
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 20 Jun 2002 08:34:21 -0700
Subject: atu and network ...
Message-ID: <3D11F5FD.BEF15D5D@snf.stanford.edu>

Bill and Mike:

Related to atu and getting to it ...

If I do a "traceroute atu" or "traceroute atu.snffab.stanford.edu" from snf,
it finds it immediately.

However if I do a "traceroute atu.stanford.edu" (also from snf) it tries to go
to quad-rtr.stanford.edu ... and then hangs.  It seems as if from snf it
should never have had to go to quad-rtr.  Does this mean that our switch is
improperly configured?

As long as we are looking at things, it also appears that the named stuff on
snf doesn't know about sunstar.snffab.stanford.edu ... which it probably needs
to do shortly.

Thanks,

John


From bmurray at snf.stanford.edu  Thu Jun 20 10:22:13 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 20 Jun 2002 10:22:13 -0700 (PDT)
Subject: CORAL shutdown e-mails
In-Reply-To: <3D11FA33.992B3A0E@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10206201019110.12439-100000@snf.stanford.edu>

Len,

Thanks!  This is the same problem we saw last time.  It appears that
this is related to a known bug in the Oracle jdbc driver.  We're in
the process of moving to a new version of Oracle (9i) where this bug
has been fixed.  If the problem still occurs with the new driver, then
I may have a bug.

I've restarted the servers.

Thanks again,
Bill

On Thu, 20 Jun 2002, Len Booth wrote:

> Bill - -
>         yesterday at 15:49 the p5000etch was shutdown on CORAL
> but I did not receive an auto e-mail from CORAL.
>         the client equipment status light is red
> 
>         yesterday at 15:19 the pquest was shutdown on CORAL
> but I did not receive an auto e-mail from CORAL.
> the client equipment status light is red
> 
>         Is something wrong?  Normally I get an e-mail for
> new problems & shutdowns on all my equipment.
> 
>                         thanks,
>                         Len
> 



From bmurray at snf.stanford.edu  Thu Jun 20 10:28:00 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 20 Jun 2002 10:28:00 -0700 (PDT)
Subject: Coral Problem
Message-ID: <Pine.LNX.4.04.10206201025160.12439-100000@snf.stanford.edu>

John and Mike,

I've saved the logs in lastlog when I restarted the servers this morning.
I'm currently reviewing the logs to determine if this problem is related to 
the jdbc driver hanging or a bug of mine.

Bill 





From bmurray at snf.stanford.edu  Thu Jun 20 10:47:10 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 20 Jun 2002 10:47:10 -0700 (PDT)
Subject: Coral
Message-ID: <Pine.LNX.4.04.10206201045130.12714-100000@snf.stanford.edu>

Len,

Any additional information about the state of equipment in Coral after
the restart would be helpful.  Are any lights out of sycn?  Do the number
of unresolved problems and shutdowns look correct?

Thanks for you help,
Bill 




From mtang at snf.stanford.edu  Thu Jun 20 15:39:41 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Thu, 20 Jun 2002 15:39:41 -0700
Subject: SunRay cards
Message-ID: <3D1259AD.5FCE8C55@snf.stanford.edu>

Hello Coral Dev Team!

Sorry guys, we're out of SunRay cards.  I know that people keep them and
shouldn't, but there you go -- we're out...  Do you have more handy by
any chance?  (Barring that, I'll have to go through people's storage
bins...)

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




From bmurray at snf.stanford.edu  Fri Jun 21 14:45:29 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 21 Jun 2002 14:45:29 -0700 (PDT)
Subject: atu and network ...
In-Reply-To: <3D11F5FD.BEF15D5D@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10206211351220.1474-100000@snf.stanford.edu>

John,

I belive that Mike and I have fixed all the network problems on atu and snf.

The servers are now running and able to find the IOR at atu.stanford.edu.

See my comments below regarding the problems you identified.

Bill


On Thu, 20 Jun 2002, John Shott wrote:

> Bill and Mike:
> 
> Related to atu and getting to it ...
> 
> If I do a "traceroute atu" or "traceroute atu.snffab.stanford.edu" from snf,
> it finds it immediately.
> 
> However if I do a "traceroute atu.stanford.edu" (also from snf) it tries to go
> to quad-rtr.stanford.edu ... and then hangs.  It seems as if from snf it
> should never have had to go to quad-rtr.  Does this mean that our switch is
> improperly configured?


This problem was due to the netmask not being set correctly on snf.
Since Jason assigned us an ip address for atu on the "101" network
(171.64.101.xxx), snf attempted to go out the quad-rtr to find atu.
We changed the netmask from 255.255.255.0 to 255.255.254.0 so that snf
was aware that 171.64.100.xxx and 171.64.101.xxx were on the same segment.

To resolve the problem we were having getting to the IOR via 
atu.stanford.edu, we had to modify /etc/defaultrouter on atu to
include the following 
171.64.100.1
171.64.101.1

> 
> As long as we are looking at things, it also appears that the named stuff on
> snf doesn't know about sunstar.snffab.stanford.edu ... which it probably needs
> to do shortly.
> 

We're trying to resolve a problem with sunstar's ip address.  The university's
dns servers don't recognize the ip Jason assigned us.  Mike's talking with
Jason about this at the moment.

Thanks,
Mike and Bill



From bmurray at snf.stanford.edu  Fri Jun 21 17:02:40 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 21 Jun 2002 17:02:40 -0700 (PDT)
Subject: Coral Security Issues
Message-ID: <Pine.LNX.4.04.10206211651200.3619-100000@snf.stanford.edu>

John,

I've noticed a couple of issues during my attempts to get remote coral
running on atu.  (I don't expect you to do anything about these items.
I'm just sending this as a reminder to us both to resolve them at some
point.)  First, the encrypted remote passwords stored in 
/usr/local/coral/etc/private/shadow on atu (and on platinum2 at psu)
should be created with permissions 600 instead of 644.  Although this
is not a serious problem because the private key is required to 
decrypt these passwords, this should be corrected.  If I remember 
correctly, this cannot be done from the auth manager because file
permissions vary across operating systems so there is no standard 
mechanism to do this.  I believe we handled this by setting the 
appropriate umask for the user athmgr.  For the moment, I went out
on atu and platinum2 and changed the existing password file permissions
to 600.

The second problem is serious.  When the athmgr creates the .keystore
file which contains the private key, its permissions are also set to
644.  If we correct the umask problem before running the athmgr the
first time, this problem will also be resolved.  For now, I have gone
out to atu and platinum2 and changed the .keystore permissions to 400.

Bill






From mtang at snf.stanford.edu  Sat Jun 22 13:37:00 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Sat, 22 Jun 2002 13:37:00 -0700
Subject: Coral down...
Message-ID: <3D14DFEC.3D8E6CBD@snf.stanford.edu>

Sory to bug you guys, but Don Arnold reports that Coral is down.
There's a nice, big fat hourglass on all the Coral terminals and there
is no response from any input (mouse, keyboard, Coral card....)

Help!

M

--
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  Sat Jun 22 15:24:00 2002
From: shott at snf.stanford.edu (John Shott)
Date: Sat, 22 Jun 2002 15:24:00 -0700
Subject: Coral down...
References: <3D14DFEC.3D8E6CBD@snf.stanford.edu>
Message-ID: <3D14F900.CFD680E4@snf.stanford.edu>

Mary, Bill, Mike, and Jason:

It appears as if we are having a network problem on the fiber link between the
Sunray and the switch in the fingerwall ... at least that is what it looks
like to me.

In particular, there are some messages in /var/adm/messages saying:
sbus-gem0: Could not establish link, check if cables are plugged in.

I've rebooted sunray, power cycled our switch in the fingerwall ... all to no
avail.

I'll make another round, try to connect and disconnect fiber segments into the
switch and into sunray ... I think there may be a connection in the "cage",
but I doubt that I can do anything there.

Does anyone know of any diagnostics we can run?  We also have, I think, the
fiber signal tester ... but I don't know how to use it.

I'll send out e-mail and post signs indicating that Sunray (and as a result
in-lab) Coral are dead although Remote Coral should (and does) work ...

So, as of 3:30 p.m. afternoon on Saturday (and, apparently, this was first
noticed this morning ....) our SunRays have been hourglassed ...

Thanks,

John

P.s. also in the Sunray /var/adm/messages files, it appears as if 00:53 this
morning that there was some sort of a CPU 15 memory problem that seemed to
have caused a reboot of sunray ... at first inspection, however, I didn't see
signs of this when I rebooted.


From shott at snf.stanford.edu  Sat Jun 22 16:22:50 2002
From: shott at snf.stanford.edu (John Shott)
Date: Sat, 22 Jun 2002 16:22:50 -0700
Subject: Network fiber problem appears to be OK ... at least for now.
Message-ID: <3D1506CA.2F2948ED@snf.stanford.edu>

Mike, Bill, Mary, and Jason:

I believe that the fiber connection is back and that the Sunrays are back
alive.

We seem to have 2 fiber interfaces on our 3900 switch ... and only had one
pair of fibers plugged in in the fingerwall.

What I did was ... unplug and replug the fiber in the "main" interface (which
is the leftmost fiber pair as seen from the back of the 3900 (if one could
actually get behind the 3900 ...)

Then I was that there was a second labelled pair ... and plugged them into the
next (to the right) fiber port.

By the time I could get out of the fingerwall, the SunRays were back up.  So,
I don't know exactly whether the first fiber had failed, the first interface
had failed, or there was simply "iffy" optical contact in the first fiber ...
in other words, adding the second fiber may have done nothing.

Since I am not "Mr Fiber" I don't propose to do any further diagnostics but we
should probably take a look on Monday to see if we are "hanging by a thread"
... I know, bad choice of words for a fiber optic problem.

Since we are on the verge of firing up Sunstar (which gives us server
redundancy), we should probably look at our fiber/switch situation to see if
we can eliminate singe points of failure.

But, at least we seem to be alive ... Coral-wise.

Have a good weekend,

John


From bmurray at snf.stanford.edu  Mon Jun 24 17:01:30 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 24 Jun 2002 17:01:30 -0700 (PDT)
Subject: Status
Message-ID: <Pine.LNX.4.04.10206241657470.7577-100000@snf.stanford.edu>

John,

The hub in the student area is working properly. 

The network cable to crystal and the corresponding port on the switch have
been switched.

Finally, we vacuumed up all the debris in the fingerwall where our two
switches reside.  Mike showed me how to use the fiber tester on the 
spare cable.

Mike and Bill 




From shott at snf.stanford.edu  Tue Jun 25 09:34:01 2002
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 25 Jun 2002 09:34:01 -0700
Subject: Servers restarting at PSU ... need sudo
Message-ID: <3D189B79.6393DC90@snf.stanford.edu>

Bill, Mike and Mike:

In looking at the log files of the servers at Penn State, it appears as if one
of the servers died, AgentMonitor detected it, but was unable to restart them
because "sudo" isn't installed and configured.

This is my fault for having failed to tell Mike Rogosky that we need sudo. 
Mike, if you are familiar with it, sudo (which basically stands for "super
user do") is a program that allows you to give limited access to certain
people to do things that, normally, only root (or some other special
privileged person can do) ...  In coral, we use if for 2 things:

1. We have some scripts that set up new user accounts (unix accounts, that
is), changed passwords, set up mailforwarding ... we allow our administrative
types to run these scripts that normally only root can run.

2. Coral normally is started by "servers start" or "servers restart" that, in
turn, calls "server_start" for each individual server.  Normally, only root
can start the servers ... However, we use sudo so that user "admin" can
restart the servers when it detects a problem.  For convenience, it probably
also makes sense for you (and maybe Guy?) to be set up so that you can restart
them as you, without having to be root.

If it is OK with you, Mike, I'll go ahead and setup sudo on platinum2 ... it
will likely be installed in /usr/local/bin/sudo.

Thanks,

John


From mrogosky at engr.psu.edu  Tue Jun 25 10:37:21 2002
From: mrogosky at engr.psu.edu (Michael Rogosky)
Date: Tue, 25 Jun 2002 13:37:21 -0400
Subject: Servers restarting at PSU ... need sudo
Message-ID: <937AC68A9AFF694991B176C5E1383117BB9696@engrmail1.engr.psu.edu>

John,

I am familiar with sudo.  Thank you for offering to install it!  Go ahead an do it and just let me know where the config file is in case I need to add to it in the future.

Thanks!
-Mike



> -----Original Message-----
> From: John Shott [mailto:shott at snf.stanford.edu]
> Sent: Tuesday, June 25, 2002 12:34 PM
> To: coral at snf.stanford.edu; Michael Rogosky
> Subject: Servers restarting at PSU ... need sudo
> 
> 
> Bill, Mike and Mike:
> 
> In looking at the log files of the servers at Penn State, it 
> appears as if one
> of the servers died, AgentMonitor detected it, but was unable 
> to restart them
> because "sudo" isn't installed and configured.
> 
> This is my fault for having failed to tell Mike Rogosky that 
> we need sudo. 
> Mike, if you are familiar with it, sudo (which basically 
> stands for "super
> user do") is a program that allows you to give limited access 
> to certain
> people to do things that, normally, only root (or some other special
> privileged person can do) ...  In coral, we use if for 2 things:
> 
> 1. We have some scripts that set up new user accounts (unix 
> accounts, that
> is), changed passwords, set up mailforwarding ... we allow 
> our administrative
> types to run these scripts that normally only root can run.
> 
> 2. Coral normally is started by "servers start" or "servers 
> restart" that, in
> turn, calls "server_start" for each individual server.  
> Normally, only root
> can start the servers ... However, we use sudo so that user 
> "admin" can
> restart the servers when it detects a problem.  For 
> convenience, it probably
> also makes sense for you (and maybe Guy?) to be set up so 
> that you can restart
> them as you, without having to be root.
> 
> If it is OK with you, Mike, I'll go ahead and setup sudo on 
> platinum2 ... it
> will likely be installed in /usr/local/bin/sudo.
> 
> Thanks,
> 
> John
> 


From bmurray at snf.stanford.edu  Thu Jun 27 10:06:00 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 27 Jun 2002 10:06:00 -0700 (PDT)
Subject: July 17 Conference
Message-ID: <Pine.LNX.4.04.10206270959350.27421-100000@snf.stanford.edu>

John and Mike,

I was hoping to divide up the agenda items so that at least one of us 
would be assigned to each of the topics to make sure we stay on track.
Here's the latest agenda with tentative assignments.  Is this ok?

Bill

			Proposed Agenda Topics

-Demo of MIT's Recipe Manager prototype written by Jeff Klann.  This will
 give UCB an opportunity to review and make comments and suggestions.  
 The developers will need some time to discuss the best strategy for
 integrating this work with the existing system. (Bill)

-Demo of MIT's Equipment Status client written by Ike Lin.  Can we
 integrate this functionality with an improved Maintenance client and
 also begin to add some of the features of the Faults system at UCB?
 (Bill)

-How can our architecture evolve to accommodate the use of new technologies
 like "Web Services"?  Technology continues to change and improve.  How
 can we take advantage of the new tools available in the marketplace?  I
 have been discussing these issues with Firenc at UCB over the last couple
 of months.  I hope he will be able to join us and share his thoughts.
 (Mike)

-Review each site's prioritized list of Coral enhancements and modifications.
 (John)

-Coral Development Process.  Is there a methodology that will work for us?
 Mike Bell will review our choice of IDE and UML tools.  (Mike)

-Review the status of Coral installations at other sites: Penn State,
 the University of Minnesota, UCLA, the University of Arkansas, ...
 (John Shott)

-Review Mike Bell's proposed architecture for the new Inventory module.
 (Mike)

-microCoral: Coral on a PDA? (Bill)

-Walker Boxes and Equipment Control Cards.  We would like to place a
 large order with Dr. Walker for boxes and cards.  If anyone anticipates
 needing additional hardware over the next year, now would be the time
 to place that order.  Bring your list. (John)

Thanks,
Bill Murray