From shott at snf.stanford.edu Tue Apr 2 17:36:05 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 02 Apr 2002 17:36:05 -0800 Subject: Updated Coral Wish List .... Message-ID: <3CAA5C85.B17AF716@snf.stanford.edu> Bill and Mike: Following is the wish list that I generated a month or so ago ... I've now updated this to reflect recent progress and added a few things that, I believe, represents a preliminary set of "new challenges" that may have emerged at Java One and elsewhere. I've also tried to make a preliminary estimate of "priority" and "effort required". This is still a working list and doesn't really include proper prioritization ... Hardware Stuff: 1. Install Solaris machines, including RAID disks, SunRay failover, etc. (Well, this includes software stuff as well ... Oracle 8.1.7, etc.) ... Mike's made recent good progress in this area. At some point, before we can test failover, I think that we probably need to upgrade the SunRay server software on Sunray from version 1.1 to 1.3. 2. Get faster Linux box for development effort (probably in one of the black rackmount boxes). ... I think that we are done here. 3. Improve firewall machines ... Low priority. Overall Software Stuff: 1. Deploy Coral at Penn State ... Our highest priority!!! I have to be able to tell NSF that it is running at Penn State on May 6. 2. Deploy Coral at MIT ... While they aren't yet in production, it appears that Ike has been making excellent progress and at least has a development version of coral running against Oracle 8.1.7 and has functional servers, clients, and remote clients. Major progress!!! 3. Deploy Coral at UCB .... Hmmm. Apparently no good news here ... 4. Update firewall software including mechanism to allow rosen to communicate through the firewall with remote clients. ... Probably pretty low priority as few servers are likely to run from behind firwalls. We probably have multiple options including "SOAPing" the remote client, simply buying something that allows CORBA through a firewall, etc. 5. Update daemon/driver to run under newer versions of RedHat and consider updating walker to that version. ... Nothing done here. Low priority until we want to look at something like facility monitoring or sensor reading. Supporting software Stuff: 1. Finish update of adjustments in monthly accounting scripts. ... Bill is working on this as we speak, including improved support of multiple "types" of projects. (Actually, the adjustment part is fine ... it is updating them for Postgres and incorporating different rates for different "type" of project that is the main activity. 2. Finish sprucing up Makefiles including rsync stuff. ... While it's not perfect, I think that we've made good progress here and have improved this significantly. 3. Update newuser, and set_password for rsync. ... Nothing done. Improvements here would probably be useful at MIT and Penn State, too. Also, once these scripts are spruced up, we should insert them into the resource client so that "Add member" not only adds them to the database, but sets up an account for them as well. 4. Study and adopt "report generation" strategy. Ideally an affordable, commecial means of generating Excel files from our database with "pre-canned" queries. ... No real progress here. Predominantly Server Side Stuff: 1. "Configuration manager" capabilities with more parameters coming from the DB (where possible). ... Bill, am I remembering correctly that this is one of the places where JDOM and XML documents look to be of use? 2. Admin manager update to start/stop other servers. ... This would be nice (particularly as it would allow servers to be started in "as soon as the previous server was up" timing instead of the fixed timing that we use in the current servers script. However, I'm not sure that this is, by itself, a terribly high priority. However, it is likely that this would be done when improved monitoring and logging are done. 3. Admin manager monitoring of performance statistics. ... I think that this is also an area for incorporation of the 1.4 logging mechanism and allows us to remotely monitor not only our servers and clients ... but those at other sites as well. This could be one of the most important areas that would allow us to support other sites running Coral. 4. Migrate from ABA JCE stuff to Bouncy Castle. (I'm worried that a soon as JDK 1.4 if officially released that we will begin to see people running 1.4 on their Remote Coral machines. As soon as they do, I fear that Remote Coral will break because it comes with the Sun JCE stuff pre-installed. I think that the solution may be to convert to BouncyCastle. If someone is running 1.4 on their remote machine, then they only need to download the BC provider. If, however, are running on a 1.3+ machine, then they would need to download the signed BC JCE implementnation plus the BC provider ... at least I think that is what is required). Note: this assumes that BC encryption/decryption can decipher the existing ABA encryption ... I don't know that is true. Predominantly Client Side Stuff: 1. Add "Replace Project for all Members" (that is ... for every member that has an active ability to charge to Project A, terminate that works_on entry and add a new ability to charge to Project B (with appropriate actions in various activity/adjustment tables ...) (I've actually notices a few funny things with the resource client ... for example, after selecting a new member and then doing an "Edit member", I got the info for the previously selected member instead of the currently selected one ... I don't know how reproducible this is, but ...) 2. Come up with a way of displaying all reservations for a given person on a signle GUI panel. ... Probably lots of people would like this. 3. On history panel, add "red" and "yellow" shading for problem/shutdown periods. ... Not a terribly high priority, but it should be comparatively easy to do. 4. Resource client needs some "repaint cleanup". For example, pulldown menus often continue to display (at least partially) after they are no longer in use. 5. Add "labwho" capability that shows who is in the lab (based on info in current_lab). Both Client/Server Side: 1. Inventory Client/Server ... High priority. 2. Recipe Client/Server 3. Think about and implement "more than one lab" capability. ... it's not completely clear taht this is needed. 4. Look at using "Walker boxes" for door interlock hardware including explicit addition of "Enter Lab" and "Exit Lab" pulldown menu items (note: these Enter Lab and Exit Lab menu items are actually different than the enterLab and related method in the Admin Manager. (Actually, it would nice to be able to add support for multiple doors ... including the main lab door, add hardware to control the "blue coat" maintenance entrance, room 151, etc. 5. Update/adoption of Berkeley "Faults" system. 6. Facilities monitoring client/server/hardware ... there are lots of interesting things that could be done here and many of them would be used by lots of different labs. Let me know if you have additions to this list or don't understand what I mean by some of these items. Actually, I think that there a few other things that might be useful to add based on some of the things that were learned or seen at Java One: 1. Consider a PDA-Coral .... this could be fun, have lots of "Gee Whiz" appeal, and even be useful. 2. Explore an appropriate development environment ...Sun Forte and Eclipse (which, I gather, is the public domain version of VisualAge for Java). Ike seems to like Forte ... and likes VA even better so it would appear that either Forte and/or Eclipse may be in our future ... 3. Ultimately migrate to an ant build process ... probably makes sense in the long run and would be smart for a brand new project but is a lower priority since we have so much invested in the Makefiles and they appear to work reasonably well. 4. Equipment monitoring, data extraction, and recipe downloading ... there appear to be serveral Java SECS implementations including J-SECS from ErgoTech. This might be a good area of some initial exploration of xml documents for specifying recipes and/or measurement and using J-SECS (or equivalent) for the low level communication of this information to/from equipment. I've probably forgotten more things ... every time I think about this, I can come up with something that we've forgotten. Talk to you later, John From bmurray at snf.stanford.edu Wed Apr 3 13:56:01 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 3 Apr 2002 13:56:01 -0800 (PST) Subject: Coral forwarding (fwd) Message-ID: John, This may not be trivial to accomplish. How do you want to handle these requests? Bill ---------- Forwarded message ---------- Date: Wed, 3 Apr 2002 11:09:19 -0800 From: Rajashree Baskaran To: bmurray at Stanford.EDU Subject: Coral forwarding hello I am an outside academic user at SNF. I hae plans to work in 3-4 week periods and not continously. Is there a way, i can stop and start email forwarding from the snf ID to my regular ID..while i would very much like to read the emails from other users et al while I am using the fab, its a bit too many at times i am not working there. Thanks, Sincerely Rajashree Coral login :raji From shott at snf.stanford.edu Mon Apr 8 10:22:24 2002 From: shott at snf.stanford.edu (John Shott) Date: Mon, 08 Apr 2002 10:22:24 -0700 Subject: Updates wish list ... Message-ID: <3CB1D1D0.AB1D9689@snf.stanford.edu> Bill and Mike: Following is my updated Coral wish list including a very preliminary attempt at prioritizing things. If this looks OK (or, once it looks OK ...) I'll plan to send this to MIT. Please let me know if there are things that I've forgotten, overstated, understated, etc ... Stanford-specific matters: 1. Install Solaris machines, including RAID disks, SunRay failover, etc. (Well, this includes software stuff as well ... Oracle 8.1.7, etc.) ... Mike's made recent good progress in this area. At some point, before we can test failover, I think that we probably need to upgrade the SunRay server software on Sunray from version 1.1 to 1.3. ... High priority. 2. Acquire technology so that remote clients can reach our servers through a firewall so that we can put our servers fully behind a firewall once again. Candidates includue the Domain Boundary Controller from www.xtradyne.com. Other options may include CORBA-aware firewalls. Alternatively, we could conisder adapting the remote client to use SOAP instead of CORBA communications. ... Medium priority. (Note: I put this in the Stanford-only list because it is not yet clear that there are other sites that will be running their database/system from behind a firewall ... if there are, then this becomes a broader issue). 3. Improve firewall machines ... Low priority (but probably should be done at the same time that we handle #2 above). MIT-specific matters: I'll let Ike and Tom fill this in .... Overall Coral Matters: 1. Deploy Coral at Penn State ... Our highest priority!!! I have to be able to tell NSF that it is running at Penn State on May 6. This requires 3 things: a. We need equipment/accounting initial table population from Penn State b. I need to be able to convert their tab-separated files into appropriate Postgres "Insert" statements. c. Bill needs to finish adding different charge rates for different "types" of users (local, industrial, etc.) and get the accounting stored procedures working with them. (This, of course, implies that they will work with Postres as well.) 2. Deploy Coral at MIT ... Major progress!!! Ike and Tom have a development version working with Oracle 8.1.7. Hooray!!! Ike and Tom: we need to know what the hurdles are between now and getting things in production ... 3. Deploy Coral at UCB .... Hmmm. Apparently no good news here ... 4. Explore an appropriate development environment ...Sun Forte and Eclipse (which, I gather, is the public domain version of VisualAge for Java). I also gather that VisualAge had had its last release and that future enhancements will be applied to Eclipse. I think that Ike has the most experience with these systems ... Ike and Mike should work together to see what fits best in our environment. 5. Spruce up the resource client/server so that "add member" actually adds the new member to the database (which it already does) AND gives them a system account, sets up mail forwarding appropriately, etc. These are currently done by separate scripts that are not run from the resource client/server. We should factor this in with the JNI auth things that MIT is interested in pursuing ... 6. Study and adopt "report generation" strategy. Ideally an affordable, commecial means of generating Excel files from our database with "pre-canned" queries. ... Commercial candidates include e.Spreadsheet (formerly Formula One from Tidestone) from Actuate or products from www.jinfonet.com and www.extentech.com (ExtenXLS), and probably others. e.Spreadsheet is nice, but pricey! No real progress here. 7. Update daemon/driver to run under newer versions of RedHat and consider updating walker to that version. ... Nothing done here. Low priority until we want to look at something like facility monitoring or sensor reading. 8. Consider a PDA-Coral client running on top of J2ME .... this could be fun, have lots of "Gee Whiz" appeal, and could be increasingly useful. But it is probably a lot of work to figure out how to make some of the essential clients Palm compatible. 9. Ultimately migrate to an ant build process ... probably makes sense in the long run and would be smart for a brand new project but is a lower priority since we have so much invested in the Makefiles and they appear to work reasonably well. Also, the "non-Java" stuff that we need to support including SQL stuff, shell scripts, JNI things, etc., may offer a coplication in adopting the ant build route. 10. Equipment monitoring, data extraction, and recipe downloading ... there appear to be serveral Java SECS implementations including J-SECS from ErgoTech. This might be a good area of some initial exploration of xml documents for specifying recipes and/or measurement and using J-SECS (or equivalent) for the low level communication of this information to/from equipment. Probably a fairly low priority until there is a louder cry for actual communication with hardware (other than enable/disable stuff, of course) ... and a lot of work. Predominantly Server Side Stuff: 1. Enahnced "configuration manager" capabilities with more parameters coming from the DB (where possible). ... Bill, am I remembering correctly that this is one of the places where JDOM and XML documents look to be of use? 2. Admin manager update to start/stop other servers. ... This would be nice (particularly as it would allow servers to be started in "as soon as the previous server was up" timing instead of the fixed timing that we use in the current servers script. However, I'm not sure that this is, by itself, a terribly high priority. However, it is likely that this would be done when improved monitoring and logging are done. 3. Admin manager monitoring of performance statistics. ... I think that this is also an area for incorporation of the 1.4 logging mechanism and allows us to remotely monitor not only our servers and clients ... but those at other sites as well. This could be one of the most important areas that would allow us to better support other sites running Coral. Because of its felxibility, adopting the new 1.4 logging mechanisms as a replacement to the System.out.println and System.err.println statements is probably a good thing to begin to work into the overall system. If we gain a little experience, this may be able to be added incrementally one client or server at a time. 4. Migrate from ABA JCE stuff to Bouncy Castle. (I'm worried that a soon as JDK 1.4 if officially released that we will begin to see people running 1.4 on their Remote Coral machines. As soon as they do, I fear that Remote Coral will break because it comes with the Sun JCE stuff pre-installed. I think that the solution may be to convert to BouncyCastle. If someone is running 1.4 on their remote machine, then they only need to download the BC provider. If, however, are running on a 1.3+ machine, then they would need to download the signed BC JCE implementnation plus the BC provider ... at least I think that is what is required). Note: this assumes that BC encryption/decryption can decipher the existing ABA encryption ... I don't know that is true. Predominantly Client Side Stuff: 1. Add "Replace Project for all Members" (that is ... for every member that has an active ability to charge to Project A, terminate that works_on entry and add a new ability to charge to Project B (with appropriate actions in various activity/adjustment tables ...) (I've actually noticed a few funny things with the resource client ... for example, after selecting a new member and then doing an "Edit member", I got the info for the previously selected member instead of the currently selected one ... I don't know how reproducible this is, but ...) Also, many of the popup windows come up with a size that shows most of the fill-in fields as being zero-width. I think that this is because we are specifying the popup window size at a high level ... rather than letting it be the size that it prefers to be. 2. Come up with a way of displaying all reservations for a given person on a single GUI panel. ... Probably lots of people would like this. 3. On history panel, add "red" and "yellow" shading for problem/shutdown periods. ... Not a terribly high priority, but it should be comparatively easy to do. 4. Resource client needs some "repaint cleanup". For example, pulldown menus often continue to display (at least partially) after they are no longer in use. 5. Add "labwho" capability that shows who is in the lab (based on info in current_lab). 6. Rework the maintenance client to be more user friendly. At a minimum, it needs to be able to display the entire text of problem/shutdown messages. Both Client/Server Side: 1. Inventory Client/Server ... High priority. 2. Recipe Client/Server ... MIT is driving the bus here, but I think that at least rudimentary capability in this regard is a high priority. 3. Think about and implement "more than one lab" capability. ... it's not completely clear that this is needed. 4. Look at using "Walker boxes" for door interlock hardware including explicit addition of "Enter Lab" and "Exit Lab" pulldown menu items (note: these Enter Lab and Exit Lab menu items are actually different than the enterLab and related method in the Admin Manager. (Actually, it would nice to be able to add support for multiple doors ... including the main lab door, add hardware to control the "blue coat" maintenance entrance, room 151, etc. 5. Facilities monitoring client/server/hardware ... there are lots of interesting things that could be done here and many of them would be used by lots of different labs. For starters, this would be using the Walker ISA card to interrogate 4-20 mA sensors to read pressures, temperatures, etc. 6. Update/adoption of Berkeley "Faults" system. This will probably wait for UCB to be fully on board as they will be the likely driving force here. Let me know if you have additions to this list or don't understand what I mean by some of these items. It's clear that there are a long list of enhancements and improvements that can be added to Coral. As usual, your comments, suggestions, and corrections are welcome. Thanks, John From chquay at MtHolyoke.edu Wed Apr 17 10:03:27 2002 From: chquay at MtHolyoke.edu (Charis Quay Huei Li) Date: Wed, 17 Apr 2002 13:03:27 -0400 (EDT) Subject: problems with remote coral Message-ID: Hello, I'm having problems using remote coral. I've installed Java Web Start, but when I click on 'Launch Remote Coral' on the SNF page, it gives me an eroor and won't start. When I click on Details, here's what I get: An error occurred while launching/running the application. Category: Invalid Argument error Could not load file/URL specified CouldNotLoadArgumentException[ Could not load file/URL specified] at com.sun.javaws.Main.main(Unknown Source) java.io.FileNotFoundException: C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\85WTUFW5\coral[1].jnlp (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(Unknown Source) at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source) at com.sun.javaws.Main.main(Unknown Source) I'm wondering if this is a problem with my computer...or if it's just the program. I live in Lyman on campus and this is the firs ttime I'm trying to run Remote Coral. My machine is Windows 2000. Please advise. THanks. Cheers, Charis. From shott at snf.stanford.edu Wed Apr 17 17:03:05 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 17 Apr 2002 17:03:05 -0700 Subject: problems with remote coral References: Message-ID: <3CBE0D39.99E0C076@snf.stanford.edu> Charis: I've got a couple of thoughts: First, remote coral is never going to run for you until you set a remote password. So, the next time that you have a local version of Coral running, on the leftmost menu item, select "Set Remote Password" and set a remote password for yourself. It can be the same as your "normal" coral password, if you wish, but it has to be set locally before coral can run remotely. Next, I would suggest: 1. This type of problem often occurs when the Java Web Start cache gets confused. The best way to fix this is to start up the Java Web Start application itself, click on "Remote Coral", the pull down the "Application" menu and select "Remove Application". Exit from Java Web Start. 2. Then go to our web site and download a "fresh" copy of Coral. Let me know if this works, John From chquay at MtHolyoke.edu Fri Apr 19 01:24:51 2002 From: chquay at MtHolyoke.edu (Charis Quay Huei Li) Date: Fri, 19 Apr 2002 04:24:51 -0400 (EDT) Subject: problems with remote coral In-Reply-To: <3CBE0D39.99E0C076@snf.stanford.edu> Message-ID: Dear Mr. Shott, Thank you for your prompt response. I do have a remote coral password. Since I sent you the last e-mail I tried logging in from my lab and had no problem at all. However, the connection from home is still presenting problems. I've uninstalled and reinstalled Java Web Start at least 5 times now including 2 completely fresh downloads. Coral does not appear in the JWS menu probably because I've never been able to launch it. (I only see programs like Draw and SwingSet.) Your e-mail seems to suggest that I should download Remost Coral seperately from JWS? How do I do this? It does not appear to be in the instructions on the website and in fact, just following the instructions there worked fine for logging in from my lab. Please advise. I'm quite confused. Thanks. Cheers, Charis. On Wed, 17 Apr 2002, John Shott wrote: > Date: Wed, 17 Apr 2002 17:03:05 -0700 > From: John Shott > To: Charis Quay Huei Li > Cc: coral at snf.stanford.edu > Subject: Re: problems with remote coral > > Charis: > > I've got a couple of thoughts: > > First, remote coral is never going to run for you until you set a remote > password. So, the next time that you have a local version of Coral running, > on the leftmost menu item, select "Set Remote Password" and set a remote > password for yourself. It can be the same as your "normal" coral password, if > you wish, but it has to be set locally before coral can run remotely. > > Next, I would suggest: > > 1. This type of problem often occurs when the Java Web Start cache gets > confused. The best way to fix this is to start up the Java Web Start > application itself, click on "Remote Coral", the pull down the "Application" > menu and select "Remove Application". > Exit from Java Web Start. > > 2. Then go to our web site and download a "fresh" copy of Coral. > > Let me know if this works, > > John From bmurray at snf.stanford.edu Fri Apr 19 18:14:37 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 19 Apr 2002 18:14:37 -0700 (PDT) Subject: Oracle on atu Message-ID: John, Mike and I have gotten Oracle 9i installed, and all the Coral tables created on atu! We had to make some minor changes to the sql scripts to support changes in 9i. I have not checked these changes in yet. When I removed the log files in sql, I was able to get make to run in the proper order. If you want to give it a try, just remove the log files in /home/labnet/.prod-install/labnet/sql on atu and run make. Have a great weekend, Mike and Bill