From mbell at snf.stanford.edu Mon Feb 5 13:50:18 2001 From: mbell at snf.stanford.edu (Mike Bell) Date: Mon, 05 Feb 2001 13:50:18 -0800 Subject: resurection of Quasi Message-ID: <3A7F201A.47E62414@snf.stanford.edu> Coral team, If it's true that the problem we had on Rosen is related to the known sbus problem and 2 NICs. It seems likely that we can revive the old Quasi box which could then be used as a spare for Rosen. I've verified that the Ultra2 is under warranty (they will "book it" this week, but can't explain why it took so long), but this would give us a more immediate backup solution until we get new hardware. While this is not Java coding related I think it may be a good use of my time as it will provide some insight into the existing problem with Rosen, maybe even a fix. Right now, of course, rebooting Rosen is perilous since it comes up with a bus error and at least the last time took several reboots. I would test this on the revived Quasi and then implement the "patch" on Rosen. Mike From bmurray at snf.stanford.edu Wed Feb 7 16:35:30 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 7 Feb 2001 16:35:30 -0800 (PST) Subject: New Tagged Release Message-ID: I have just installed and tagged our latest release of Coral (1.2) which includes our rewrite of the event service. Here is a list of our current and scheduled production releases: Coral 1.0 (1/1/2000) First production release. Coral 1.1 (12/15/2000) Added remote coral. Coral 1.2 (2/7/2001) Added new event service. Coral 1.3 Database and code cleanup. Coral 1.4 Add new resource client. Bill and John From hopcroft at snf.stanford.edu Wed Feb 14 09:44:46 2001 From: hopcroft at snf.stanford.edu (Matt Hopcroft) Date: Wed, 14 Feb 2001 09:44:46 -0800 (PST) Subject: locked sunrays Message-ID: Hi, There seems to be a new epidemic among the Sunrays, where they get locked up partially or completely. The small green light that indicates whether a card is inserted will be stuck on, and there may or may not be a signal to the monitor. The terminal in the office area, and several in the cleanroom are afflicted that I know of. -Matt Matt Hopcroft hopcroft at snf.stanford.edu 650.736.2380 From shott at snf.stanford.edu Wed Feb 14 11:24:04 2001 From: shott at snf.stanford.edu (John Shott) Date: Wed, 14 Feb 2001 11:24:04 -0800 Subject: locked sunrays References: Message-ID: <3A8ADB54.495476C0@snf.stanford.edu> Matt: I don't know what has been causing this epidemic ... and in particular if it is a usage problem or an underlying electronic problem. However, I think that I know how to fix it: If you hit "Control-Crescent" ... in otherwords, the Control key at the same time that you hit the "Crecent" key (which is the uppermost key on the far right of the keyboard). "Control-Crescent" basically does a powercycle and downloads the firmware again (it will go through the "Big Hourglass" with - then -- then --- under them ...). I just fixed the Sunray by the office area ... if you are in the lab, I'd appreciate it if you can see if this fixes them. Thank you, John From hopcroft at snf.stanford.edu Wed Feb 14 12:20:07 2001 From: hopcroft at snf.stanford.edu (Matt Hopcroft) Date: Wed, 14 Feb 2001 12:20:07 -0800 (PST) Subject: locked sunrays In-Reply-To: <3A8ADB54.495476C0@snf.stanford.edu> Message-ID: Hi John, Thanks for the information. However, it now seems like there may be two problems. The sunray in the office area had a persistent "card light" and a green "wedge light" (the clear plastic wedge at the top of the sunray). Two sunrays in the cleanroom have a persistent card light and an orange wedge light. They don't respond to the control-crescent. Let me know if there is anything else I can do. [the affected sunrays are by wbnonmetal and drytek2] -Matt Matt Hopcroft hopcroft at snf.stanford.edu 650.736.2380 On Wed, 14 Feb 2001, John Shott wrote: > Matt: > > I don't know what has been causing this epidemic ... and in particular if it > is a usage problem or an underlying electronic problem. > > However, I think that I know how to fix it: > > If you hit "Control-Crescent" ... in otherwords, the Control key at the same > time that you hit the "Crecent" key (which is the uppermost key on the far > right of the keyboard). "Control-Crescent" basically does a powercycle and > downloads the firmware again (it will go through the "Big Hourglass" with - > then -- then --- under them ...). > > I just fixed the Sunray by the office area ... if you are in the lab, I'd > appreciate it if you can see if this fixes them. > > Thank you, > > John > From bmurray at snf.stanford.edu Wed Feb 14 14:06:47 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 14 Feb 2001 14:06:47 -0800 (PST) Subject: Coral Release 1.21 Message-ID: I have just tagged our latest release of Coral (1.21) which includes bug fixes and enhancements of the event service. Here is a list of our current and scheduled production releases: Coral 1.0 (1/1/2000) First production release. Coral 1.1 (12/15/2000) Added remote coral. Coral 1.2 (2/7/2001) Added new event service. Coral 1.21 (2/14/2001) Bug fixes and enhancements of the new event service. Coral 1.3 Database and code cleanup. Coral 1.4 Add new resource client. Bill From pruitt at stanford.edu Thu Feb 15 12:31:23 2001 From: pruitt at stanford.edu (B Pruitt) Date: Thu, 15 Feb 2001 12:31:23 -0800 Subject: no off-campus remote access Message-ID: <4.2.0.58.20010215122900.00a93cd0@pruitt.pobox.stanford.edu> I am not able to access remote coral from home anymore (cable modem service) but I can access it from my office on campus. From home I get the login window then about 5-10 minutes later get an error that the equipment can't be accessed. I've asked around and a few others report similar experiences. Any suggestions? thanks Beth Pruitt From shott at snf.stanford.edu Thu Feb 15 12:39:09 2001 From: shott at snf.stanford.edu (John Shott) Date: Thu, 15 Feb 2001 12:39:09 -0800 Subject: no off-campus remote access References: <4.2.0.58.20010215122900.00a93cd0@pruitt.pobox.stanford.edu> Message-ID: <3A8C3E6D.DF973570@snf.stanford.edu> Beth: Hmmm ... no, I don't have a great idea, but yours is not the first mention of this type. It makes we wonder whether there has been some sort of campus-wide change in networking or policy or whatever. Since I'm a complete bozo related to knowing about cable modems ... when it was working, how did you connect to us? Did you first open some sort of a connection to Stanford? And then fire up remote Coral? Any details will help me to track this problem down ... Thanks, John From mbell at snf.stanford.edu Thu Feb 15 13:46:04 2001 From: mbell at snf.stanford.edu (Mike Bell) Date: Thu, 15 Feb 2001 13:46:04 -0800 Subject: no off-campus remote access References: <4.2.0.58.20010215122900.00a93cd0@pruitt.pobox.stanford.edu> <3A8C3E6D.DF973570@snf.stanford.edu> Message-ID: <3A8C4E1C.DB1B9617@snf.stanford.edu> Beth, I think we can solve your problem. It is basically a bug in Sun's Web Start that does not down load the new version of Coral when a change is made. So, 1) Double click the Java Web Start icon You should see the Coral application. 2) If you have more than one Web Start application single click to select Coral. 3) On the Menu bar at the top select Application -> Remove from Cache. This will remove the Coral application. 4) Go back to the SNF web site and reinstall Coral by: going to http://snf.stanford.edu/ then selecting "Remote access to Coral" then selecting "Launch Remote Coral" This will reinstall Remote Coral per our previous instructions. Sorry for the inconvenience. Please let me know if these directions are solve the problem and are clear. Then I will send them to all lab members. Thanks, Mike Bell 650 725-9503 John Shott wrote: > Beth: > > Hmmm ... no, I don't have a great idea, but yours is not the first mention of > this type. > > It makes we wonder whether there has been some sort of campus-wide change in > networking or policy or whatever. > > Since I'm a complete bozo related to knowing about cable modems ... when it > was working, how did you connect to us? Did you first open some sort of a > connection to Stanford? And then fire up remote Coral? > > Any details will help me to track this problem down ... > > Thanks, > > John From shott at snf.stanford.edu Fri Feb 16 14:09:13 2001 From: shott at snf.stanford.edu (John Shott) Date: Fri, 16 Feb 2001 14:09:13 -0800 Subject: Access to SNF version of Remote Coral: Message-ID: <3A8DA509.CC03C8B1@snf.stanford.edu> Katalin, Todd, Bob, Vicky, Tom, Duane, Lynn, Karlis, Guy, Bill, Greg, Steve and Ernie: We are pleased to announce that we have a remote version of the Coral lab management system that, we believe, you will be able to run from your desktop to access the "production" version of the Coral application ... at least the version that is currently running here in the Stanford Nanofabrication Facility. We hope that this will give you a first-hand look at the current status of the Coral system. In a following message, I will provide instructions as to how to get this operational on a local machine ... we believe that it will run on Windows 95/98/NT/2000/ME and on Solaris and Linux boxes. We fear that it will not run on Macs (with the possible exception of Macs running OS X) because it appears that Apple is far behind the curve in terms of their support of recent releases of the Java Virtual Machine. The version of Remote Coral that you will be able to download is the exact version that we are running in production in our lab ... and is identical in method of deployment to what we are doing on our staff desktops, other lab members on campus, and SNF members from other universities and local industry. We are using a recently announced (but free) product from Sun called Java Web Start (information: java.sun.com/products/javawebstart). Virtues of this approach include: 1. The full Coral client application is downloaded onto your local machine in the form of a JAR file and runs on your machine ... this means that things like screen re-draw happens quickly because it is running on your local machine. The comparatively terse messages that flow between client and server mean that performance is acceptable even over a low-bandwidth network connection ... and only slightly degraded from what we see in the lab for a more reasonable network connection. I've successfully run our client over a modem! Finally, unless the Client changes (with improvements, for example ... see item #2) it only needs to be downloaded once ... not everytime you want to run the application. 2. Each time you fire up this application, Java Web Start checks to see if a more recent version of our client software is available ... it there is, it will automatically download that for you the next time it runs. This greatly simplifies the problem of deploying upgrades or worrying about folks who may be running a sadly-out-of-date version of our application. 3. With the exception of a slightly different authentication method (which we have already taken care of) the in-lab and the remote client are identical. This means that as we add enhancements to the local Coral application, they will be automatically be ready to go for the remote clients as well ... we don't have separate development paths for remote vs. in-lab applications. The only negative that we have found thus far to this approach would be if you are operating from behind a firewall ... a tightly locked firewall will not likely allow the CORBA traffic to pass (which is the underlying communication mechanism between clients and servers). It is our belief that in the not-too-distant-future more firewalls will be able to selectively pass CORBA (IIOP) cummunication traffic. (At the moment ORBIX, a CORBA vendor, supplies and sells WonderWall that is a CORBA-aware firewall ... but that costs money!) Enough about Java Web Start ... but we think that it a good way for us to deploy the Coral application remotely. Now let me tell you about the current status of Coral and how we have set up things for you: The current version of Coral is fully functional and has what we believe to be the core elements to run in laboratories such as ours. Specifically, people can make/delete reservations on equipment, enable/disable equipment when they use it, and be added to the authorized list of users for each piece of equipment. Additionally, they can report problem/shutdown conditions affecting equipment, quickly see the problem/shutdown status of each piece of equipment, and look at the history of their equipment usage. Finally, staff members can charge other lab members either for equipment usage or thier staff time ... or charge staff time to a variety of other projects set up in the database for their use. For each of you, if you didn't already have an account with us, I have set up an account that uses your e-mail login name as your Coral login name. I have also set up a password for each of you that I can communicate either via phone or alternative method. Note: at the moment we require members to set their remote password (which may be different from their "normal" password) locally (using a local Coral client) ... this allows us to limit the population who can access our system remotely to those people who are already authorized to access our system locally. Of course, you folks are all special ... we want you to be able to access our system remotely as a demonstration vehicle! We think that this approach, coupled with the fact that we are using RSA encryption/decryption of both login name and password, minimize the security risks associated with remote Coral. In fact, when you are running Coral remotely, you are not actually logged in to a Unix machine in the normal sense ... So that you may exercise the system, you have each been given "engineer" privileges on a machine named "bottlewash" ... you will find this machine as the first name listed under "Wet Benches" in our equipment hiearchy. As "engineers" of that machine, you may do all of the things that normal users can do: make reservations, enable/disable it, write up a problem or shutdown condition, etc. Additionally, you can also clear a problem or shutdown ... which is something that, normally, only maintenance staff or enginners are allowed to do. Note: "bottlewash" is a real piece of equipment ... but it isn't normally enabled/disabled by real users. I've instructed our staff to ignore any problem/shutdown conditions. Additionally, you will notice that you have all been assigned to work on a project "Demo Only" that charges to account "Demo Only" ... in that way, you can use and reserve the bottlewash without impacting our monthly billing or equipment usage statistics. Note: normally all problem/shutdown submissions or problem/shutdown clear events will send out e-mail to the maintenance/engineers of that piece of equipment ... a mailing list named bottlewash-pcs at snf.stanford.edu (the -pcs stands for problems/comments/shutdowns). As this list does not exist, you will receive a notification that that e-mail bounced if you do any problem/shutdown activities. We felt that it was less of a nuisance to the person who submitted the event to get a single "bounced mail" message ... rather than all of you getting an e-mail message each time one of us was exercising the system. Since you are only authorized to "use" bottlewash, you won't be able to actually make/delete reservations or enable/disable any other pieces of equipment in our laboratory ... you will, however, be able to look at reservations and equipment usage history on all pieces of equipment. This is all "live" data ... this is the real production database that you are connected to. I will shortly send a follow-on message with instructions as to how do download and run Remote Coral. If I remember correctly, I had previously sent each of you a Word document that describes Coral functionality and how to use the system. If I didn't send you one, or you would like another, please let me know. Thanks for your attention. If you have any comments, suggestions, or feedback related to what you see when you exercise Remote Coral, you may contact us by sending e-mail to coral at snf.stanford.edu. Contact me direclty with any questions, to get your remote password, etc. Thanks, John shott at snf.stanford.edu 650 725-3715 From shott at snf.stanford.edu Fri Feb 16 14:29:32 2001 From: shott at snf.stanford.edu (John Shott) Date: Fri, 16 Feb 2001 14:29:32 -0800 Subject: How to download, install, and run Remote Coral Message-ID: <3A8DA9CC.E29541C5@snf.stanford.edu> SNF Lab Members: Your Coral development team is pleased to announce the release of our first version of Remote Coral. We believe this will provide fully functional Coral access from areas outside the lab including: desktop machines on campus, machines at your home institution/organization for non-Stanford lab members, from your home, or from your laptop. Moreover, we believe that this will run on a wide variety of platforms including Windows (95/98/NT/2000), Solaris (SPARC and x86), and Linux (RedHat 6.1 or higher). At this point it is not yet clear that this will run on Macintosh platforms as they appear to be lagging in their support of Java ... but that may change. Deployment of the remote version of Coral relies on a product from Sun Microsystems called Java Web Start (Version 1.0). Java Web Start will allow you to download and run an application from our web site (in fact, on Windows machines it will optionally place a shortcut to Remote Coral on your desktop and a Remote Coral entry on your start menu). Java Web Start will also make sure that you have an appropriate Java Runtime Environment (JRE). Finally, when there is an new version of Remote Coral, Java Web Start will download it automatically for you. How to download and run Remote Coral: Follow these three easy (we hope) steps ... 1. The first thing that you have to do is run the on-site version of Coral, pull down the "Window" menu and select "Remote Password". This will give you the opportunity to set (or change) the password that you will use for remote access. A window will pop up that asks you to type in (and confirm) the password that you intend to use for your remote coral password. You may choose to use the same password that you use for on-site Coral ... or you may choose to use a different password. Remote Coral will not work, however, unless you have first set a Remote Password! (Demo Only users ... I've done this for you!) Why do we make you set your remote password for Coral using the on-site system? 1. This will help to insure that only legitimate SNF users can run Coral remotely. 2. Remote Coral uses a different form of password encryption than the standard Unix/Solaris password encryption that you use when you log into on-site Coral ... there is no way to "copy" your on-site password so that Remote Coral can use it as well. 2. Go to the SNF web site (http://snf.stanford.edu), click on the "Labmembers" link on the left of the page, and then click on the "Remote Coral Access" link found on that page. This will take you to the page where you will ultimately download and launch Coral Remote. However, you first need to click the link that says: "Download Java Web Start". This will take you to a Sun page where you will be able to ... well, download Java Web Start. If you will be downloading to a Windows machine, life should be easy: downloading Java Webstart also downloads and installs the appropriate JRE (Java Runtime Environment) at the same time. If you are downloading for Solaris or Linux, you will have to download an appropriate JRE (at least version 1.2.2 ...) first, install that, and then download the appropriate platform-specific version of Java Web Start. The instructions for doing any and all of these things are available on this page. Note: If you are downloading Java Web Start and the JRE (the package that you get included with the Widnows download of Java Web Start) the total download is about 6 MB of data which will take on the order of 20 minutes of download time should you be using a 56 kb modem. 3. Once you have installed Java Web Start, go back to the SNF web site and click on the Remote Coral Access page listed above. You should see a link that says "Launch Remote Coral". (Note: there will also be a link that says Launch Development Version of Remote Coral ... don't click this link, it is virtually guaranteed to fail.) If you only see a link that says something like: "You have to install Java Web Start first", this is an indication that Java Web Start is not properly installed on your machine and that will need to be addressed. Clicking "Launch Remote Coral" should begin to download the Remote Coral application onto your machine. It will then pop up a window asking if you wish to launch Remote Coral at that time ... if you do, click "Launch". (Note: it will also warn you that this application has asked for privileges on your machine ... and recommend that you not launch the application). We need to be able to open CORBA connections from your machine (and a log file is also written) for the application to run ... you have to trust that we aren't doing anything sneaky or malicious. The next thing that you should see is a window asking for your username and password. These should be your Coral login name and your REMOTE password, respectively. If you type these in successfully, Coral should start shortly. Well, it actually takes about 15 seconds for RSA encryption of your login name and password, transmision to use, decryption at our end, and then sending you a "ticket" identifying you as an authorized lab member. Once installed on your machine, you won't have to go to our Website to launch Remote Coral. In particualar, you can start Java Webstart, click the Remote Coral icon and then click "Launch". Alternatively, on Windows machines, the second time that you launch Remote Coral, it will ask you if you would like a desktop shortcut and/or Start Menu item added for Remote Coral. (Note: if you are connected via a 56 kb modem, download of Remote Coral either the first time or if there has been an update may take up to 2 minutes. Once it is downloaded, it should only take a few seconds to start up. Higher bandwidth network connections will, of course, experience proportionally shorter download times.) Best of luck ... we hope that downloading and launching Remote Coral goes smoothly for you. If you have comments or suggestions related to Remote Coral, please send them to coral at snf.stanford.edu. While we are certainly hopeful that most of you will find the downloading and launching of Remote Coral a painless process, there are so many different platforms, OS versions, network configurations, etc. that we fear that some of you will encounter difficulties. We will do our best to help you to resolve these problems ... but we stop short of doing major debugging or system configuration on your machine. Thanks for your continued support, The Coral Development Team p.s. Please don't leave Remote Coral running for extended periods of time when not in use. Everyone (including on-site users) should get in the habit of cleanly terminating Coral by clicking "Exit" on the "Window" pulldown menu when they are done with their Coral session. Why? Each time ANYONE makes a reservation, deletes a reservation, enables equipment, shutsdown equipment, etc. an appropriate event is posted that must be communicated to each and every Coral client that is running at that time. In other words, when you reserve karlsuss, for example, from 8 a.m. to 10 a.m. on Tuesday not only is this recorded in the database, but all running clients are explicitly notified of that fact by the reservation server ... well, in truth, there is something called the event server that handles this communication. In fact, even if you are the person who made the reservation, you are treated no differently than anyone else ... your confirmation of that reservation (when you name shows up in the time block) is coming from the event server. If there are a bunch of idle versions of Remote Coral ... everyone's response time will go down. Also (and this is true in the lab as well) please try to get in the habit of using the proper Exit pulldown menu item .... that way, the computer won't waste resources trying to notify Coral clients that are no longer there. One other note: even though you originally went to a Web page to download Remote Coral ... this is not a Java Applet and doesn't have to be run from the web page. In fact, you have downloaded a fully-functional client application onto your machine. As a result, we believe that you will find that screen re-painting, for example, will happen quite quickly. Moreover, since the communciation between each client and our server is rather terse and limited, we believe that you will find that the response of Remote Coral is adequate even over a 56 kb modem connection. One final note: while we have done our best to test the functionality of Remote Coral before releasing it, there may be some bugs and/or improvements to the code over the coming few weeks. Each time there is a new version of the client software, Java Web Start will download this for you. However, particularly if you are using a low-bandwidth network connection, this will increase the startup time of Remote Coral. We apologize in advance for any inconvenience this may cause ... but felt that it was important to get Remote Coral in broad use as quickly as possible. Good luck with Remote Coral ... comments, feedback, and suggestions should be sent to coral at snf.stanford.edu SNF Coral Development Team From bmurray at snf.stanford.edu Tue Feb 20 09:13:24 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 20 Feb 2001 09:13:24 -0800 (PST) Subject: Rosen Reboot Message-ID: John and Mike, I see rosen was rebooted or crashed this morning? All the Coral logs look fine. Were there any problems? Thanks, Bill From shott at snf.stanford.edu Tue Feb 20 18:44:40 2001 From: shott at snf.stanford.edu (John Shott) Date: Tue, 20 Feb 2001 18:44:40 -0800 Subject: j2se 1.3.1-beta ... Message-ID: <3A932B98.7AA85F54@snf.stanford.edu> Bill and Mike: I've installed JDK 1.3.1-beta in /usr/j2se on rosen, sunray, guilden, and bopeep. I believe that I was careful to preserve the java.policy and java.security files in /usr/j2se/jre/lib/security and to make sure that I didn't destroy the "external" jar files in: /usr/j2se/jre/lib/ext. So, when we are ready ... which I know is not now ... we should easily be able to move over to see if sun has solved the problems that plagued us in 1.3.0. Thanks, John From mbell at snf.stanford.edu Fri Feb 23 12:40:21 2001 From: mbell at snf.stanford.edu (Mike Bell) Date: Fri, 23 Feb 2001 12:40:21 -0800 Subject: database copy Message-ID: <3A96CAB5.131E1AE7@snf.stanford.edu> John and Bill, The most recent copy of the database has been copied onto Bopeep and Oracle restarted. Bill, since I plan to reformat the linux box we used for the copy soon, let me know that the copies are OK. Thanks, Mike From shott at snf.stanford.edu Sat Feb 24 08:58:39 2001 From: shott at snf.stanford.edu (John Shott) Date: Sat, 24 Feb 2001 08:58:39 -0800 Subject: Resource client ... d_account, and d_project. Message-ID: <3A97E83F.AD818FFD@snf.stanford.edu> Bill and Mike: (Bill, I think that you and I have talked about this in the past ... but I can't remember whether we discussed some/all of this when we talked about DB cleanup) We currently have the fields in the member table: d_project and d_account. It seems as if this is not optimum because there is no guarantee that the d_account is necessarily even associated with the d_project. It seems as if it makes more sense to have d_project be a field in the member table ... and then add d_account as a field in the project table. (I think that we also discussed adding a field like "PI" or maybe "supervisor" to the project table. In any event, it seems as if, in our case, one member can be authorized to work on one or more projects. Each project, in turn, can (in principle) charge to one or more accounts and therefore, I think, d_account is more of a project property than a member property. Of course, in our case, I think that our rule is that once project can only charge to one account at one time ... so the d_account will be the same as the currently active account for that project. Note: I think that this shouldn't require any changes to the charges_to or works_on tables. It may, however, require a change to the way that we are generating user tickets ... although, I think that it should be able to clean it up by listing a default project then all projects, then, for each project, a list of the default account followed by all of the accounts for that project. Also, related to the client ... it seems as if it should be configurable whether a site allows one member to work on more than one or only one project and whether one project can charge to more than one or only one account. (Our "rule" at snf is: a member can have multiple projects but each project can only charge to one account at a time ... although I don't think that we currently have anything in place that enforces the "only one account per project" rule ... Anyhow, those are my thoughts ... I'll be off during the next week. I should be able to check e-mail a time or two if there is anything important. Also, if need be, I can be reached at Heidi's cell phone number: 408 431-5827 ... even though we will be in San Diego. Have a good week, John