From bmurray at snf.stanford.edu Tue Feb 5 08:28:35 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 5 Feb 2002 08:28:35 -0800 (PST) Subject: Status Message-ID: John, I think we're almost there. The problem I'm fixing at the moment is this. The Admin Manager is writing it's URL to /home/labnet/share/IOR/AdminServerIOR on shott. The other managers are reading the IOR on bopeep at http://bopeep.snffab.stanford.edu/AdminServerIOR which contains the IOR of the servers running on guilden. Since the DocumentRoot on shott appears to be /var/www/html. I'm making a link in there to /home/labnet/share/IOR and modifying configuration files to write and look in the correct locations for the IOR. Bill From bmurray at snf.stanford.edu Tue Feb 5 15:18:11 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 5 Feb 2002 15:18:11 -0800 (PST) Subject: All Checked In Message-ID: John, I have checked in all the sql and makefile changes in labnet/sql/postgres. I have also checked in a few other logging and database changes in labnet/server/persistence. I updated everything on shott and restarted the servers. Everything appears to be running great. Although I have created the activity and accounting functions (stored procedures), I have not yet attempted to run them. I will do that now. Bill From shott at snf.stanford.edu Wed Feb 6 09:02:08 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 06 Feb 2002 09:02:08 -0800 Subject: Coral on linux update ... Message-ID: <3C616190.C3C9A154@snf.stanford.edu> Bill and Mike: I've installed the 1.4.0 Release Candidate on my linux box and restarted the servers. We still are getting the "unmarshalled" error when trying to start up the resource client. Also, I notice that I can't set a remote password. It claims that BlackBox is not initialized and earlier in the log it says "Cannot find public key file" just prior to doing the initial stuff with JCE on the client side. My guess is that either a file or permission is missing ... although it can't be too severe because admmgr appears to be able to find and initialize BlackBox just fine. Thanks, John From shott at snf.stanford.edu Wed Feb 6 09:10:13 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 06 Feb 2002 09:10:13 -0800 Subject: Remote coral client password stuff ... Message-ID: <3C616375.DEBF04DD@snf.stanford.edu> Bill and Mike: It appears that Server.conf sets: PUBLIC_KEY_FILE=/etc/coral/certs/Coral.key and Client.conf sets: PUBLIC_KEY_LOCATION=/home/labnet/lib/certs/Coral.key My guess is that the second one should be change to /etc/coral ... Also, would it be cleaner if we named them both PUBLIC_KEY_FILE so that we can ultimately only set it in one location ... I won't actually change this until you are in, Bill, but I'll bet that this will allow us to set remote passwords ... Thanks, John From bmurray at snf.stanford.edu Thu Feb 7 12:15:48 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 7 Feb 2002 12:15:48 -0800 (PST) Subject: Meng proposal In-Reply-To: <3C62DB9A.6DAFB680@mtl.mit.edu> Message-ID: Jeff and Tom, We do have all the servers up and running on a Linux box using Postgres. I'm still converting the accounting stored procedures in Oracle to functions in Postgres. I hope to finish that today. I have a rough draft on how to set up Postgres to run with Coral. It's different enough from Oracle that you have to use a different Makefile and sql scripts to create the tables. This Makefile and sql scripts are located in labnet/sql/postgres. The good news is that to run under Postgres only required the introduction of a configuration variable (set to Oracle or Postgres) and a few lines of code added to my persistence layer. We have everythin running on a 400Mhz Pentium with 128Mb of memory. John and I are spending about $500 to get a 1.5 Ghz processor, new motherboard, and 512Mb of memory. As soon as that's done, I'll finalize my HOWTO on setting up Postgres for Coral. If you like, I can go ahead and send my current draft. If Jeff checks out the latest labnet, he will get the Makefile and scripts he needs in labnet/sql/postgres. (Here's a better idea. I'll put my notes in the sql/postgres directory as README. Just remember, it's still a rough draft.) Thanks, Bill On Thu, 7 Feb 2002, Thomas Lohman wrote: > Jeff, setting up your own version but may be a very good learning experience > and help you learn how things are set up. It's usually easier to dive into > something when you're attempting to set it up for yourself. Do you have Linux > running anywhere? I think besides the JDK, the backend database is the other > piece but I believe you should be able to get Oracle in a developer setup for > free. > > Unfortunately, there isn't good HOWTO documentation and it will require > learning a little Oracle in order to set up the database, etc. If you have RH > Linux and can get Oracle Personal Developer edition or whatever Oracle offers > for free, then that would be good. Actually Bill Murray at Stanford just > mentioned that, I believe, they got things working under Postgres which is a > free relational db package that comes with RH Linux. I'm cc'ing him on this > e-mail to see if he thinks it would be a good exercise to try and set up a new > local personal version of their latest release on your home machines and to > see if RH Linux may be all you need. > > > --tom > > > Jeff Klann wrote: > > > > Hey Tom, > > > > Just checking on the status of things. It looks like you approved my MTL > > account, so I might glance at mtl-dev soon, though I won't be touching it > > much until you get the new one up. > > > > I was thinking about what you said... should I maybe set up my own machine > > (or another machine) as a dev server? At least at first, if I'm making > > significant changes and playing around, I don't want to break what you, > > your urop, and the full-time person will be doing. How much work is it to > > set up? Can it be done under WindowsXP or does it require unix? > > > > I guess that's all for now. Vicky says you guys are working with Stanford > > to help define the project's scope, so I'm waiting on that, working on the > > proposal. > > > > ~ jeff > From shott at snf.stanford.edu Thu Feb 7 14:17:51 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 07 Feb 2002 14:17:51 -0800 Subject: Linux coral server configuration stuff ... References: Message-ID: <3C62FD0F.7D003C0F@snf.stanford.edu> Bill and Mike: Just a couple of thoughts related to stuffing some new guts into the black rack-mount boxes for a Linux/Postgres Coral testbed ... I think that we should go with 1GB of main memory on the Linux box ... it's cheap and we don't want to swap. Here is my reasoning: if we had 8-10 servers each consuming 50 MB plus the database ... that would take our 500 MB. Anything beyond that would cause us to have to swap something. While it isn't something that we need to do often, when I dumped a big file like the activity table, the perl/postgres stuff got very large (> 200 MB). Memory is so cheap, that I suggest we get (and tell others they need 1GB) on the Linux box. I've also done a bit of reading about the motherborads we saw: As we thought, the Asus P4T-E requires Rambus memory. I'm not sure that we need the Rambus stuff. As near as I can tell, all of the Asus boards are fine with Linux ... The Asus P4B at $129 is the normal Pentium 4 board and the Asus P4B266 at $159 is the DDR-ram board where (I learned) DDR is double data rate. As I understand it, DDR is the poor man's Rambus .... But there is more ... there is both C 2 and C 2.5 DDR memory. I think that the C 2.5 means that you wait 2.5 clock cycles before getting anything and the C 2 means that you only wait 2 clock cycles to get anything. I believe what that means is the if you go with the C 2.5 DDR memory, it is actually slightly slower than SDRAM for small chunks of data ... and is only faster for big blocks of data like video. If I understand correctly, however, the C 2 DDR memory has the same response as SDRAM for small blocks but then wins for larger blocks. Note: I may be not fully correct on this, but I think taht is the story. So, here's what I think we should get for our Linux server ... and that we could duplicate at a later date when we think we are ready to replace SNF and Labnet with a newer faster firewall box ... Asus P4B266 mother board. P4 processor at some 1.5+ GB clock ... 1 GB of C2 DDR ram (probably in 2 512 MB chunks ...) 300 watt P4 compatible power supply 20-40 GB 7200 RPM hard drive ... Seagate Barracuda, IBM or equivalent Minimal AGP card ... I don't know that we need anything better than the cheapest we can find ... but I think we need something. If we had a 20 GB drive I'd suggest something along the lines of the following for partitions: 4 GB / 2 GB swap 4 GB /var 4 GB /opt (that has /usr/local in it for non-Coral 3rd party stuff such as emacs) 6 GB /usr/local/coral (with the bulk of that left for growth of the database and easy "one stop" backup of everything related to coral. Note: these are all quickly thought up ideas and numbers so don't hesistate to point out deficiencies in my plan. Thoughts, comments? Thanks, John From bmurray at snf.stanford.edu Fri Feb 8 10:09:43 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 8 Feb 2002 10:09:43 -0800 (PST) Subject: CORAL and Linux In-Reply-To: <3C63B6EC.B6BC983B@mtl.mit.edu> Message-ID: Tom, Red Hat Linux release 7.1 (Seawolf) Kernel 2.4.2-2 on an i686 [bmurray at shott /etc]$ rpm -q -a | grep kernel kernel-2.4.2-2 kernelcfg-0.6-9 kernel-headers-2.4.2-2 kernel-pcmcia-cs-3.1.24-2 However, it should run on any Linux. Penn State is planning on running under Mandrake Linux. Bill On Fri, 8 Feb 2002, Thomas Lohman wrote: > Bill, what specific version of Linux are you running CORAL under? > From thomasl at mtl.mit.edu Fri Feb 8 10:13:09 2002 From: thomasl at mtl.mit.edu (Thomas Lohman) Date: Fri, 08 Feb 2002 13:13:09 -0500 Subject: CORAL and Linux References: Message-ID: <3C641535.E7F3A5C6@mtl.mit.edu> What do you think about Redhat 6.2 with the latest kernel patches for that release? We can go ahead and put RH 7.2 on it with the latest patches but we haven't quite got MTL-ized install notes completely setup. Bill Murray wrote: > > Tom, > > Red Hat Linux release 7.1 (Seawolf) > Kernel 2.4.2-2 on an i686 > > [bmurray at shott /etc]$ rpm -q -a | grep kernel > kernel-2.4.2-2 > kernelcfg-0.6-9 > kernel-headers-2.4.2-2 > kernel-pcmcia-cs-3.1.24-2 > > However, it should run on any Linux. Penn State is planning on running > under Mandrake Linux. From bmurray at snf.stanford.edu Fri Feb 8 10:23:18 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 8 Feb 2002 10:23:18 -0800 (PST) Subject: CORAL and Linux In-Reply-To: <3C641535.E7F3A5C6@mtl.mit.edu> Message-ID: Tom, I think 6.2 is fine. The real issue is the kernel version, you want a 2.4 kernel though. The problem is related to the threading model on Linux. Most ORBs, Java, and our application servers rely very heavily on multi- threading. Traditionally the threading model on Linux does not scale well. For example, every thread in Linux requires 2Mb of stack space. (Of course, Sun scales extremely well.) However, the Linux guys are moving to a new threading model which will work much better. That's why you want the newer kernel. Bill On Fri, 8 Feb 2002, Thomas Lohman wrote: > What do you think about Redhat 6.2 with the latest kernel patches for that > release? We can go ahead and put RH 7.2 on it with the latest patches but we > haven't quite got MTL-ized install notes completely setup. > > Bill Murray wrote: > > > > Tom, > > > > Red Hat Linux release 7.1 (Seawolf) > > Kernel 2.4.2-2 on an i686 > > > > [bmurray at shott /etc]$ rpm -q -a | grep kernel > > kernel-2.4.2-2 > > kernelcfg-0.6-9 > > kernel-headers-2.4.2-2 > > kernel-pcmcia-cs-3.1.24-2 > > > > However, it should run on any Linux. Penn State is planning on running > > under Mandrake Linux. > From shott at snf.stanford.edu Fri Feb 8 13:20:02 2002 From: shott at snf.stanford.edu (John Shott) Date: Fri, 08 Feb 2002 13:20:02 -0800 Subject: CORAL and Linux References: Message-ID: <3C644102.5AB3C6E@snf.stanford.edu> Tom: Just to add my $.02 ... In terms of the Sun recommendations for running J2SE 1.4.0 RC they say that RedHat 6.2 and 7.1 are the officially supported platforms and they list a handfull of other versions upon which limited testing has been performed. (You can check java.sun.com/j2se/1.4/install-linux.html ...) I have read that RedHat 7.0 had some serious issues relative to Java ... also there is a note about running 1.4.0 RC on RedHat 6.2 as root ... something about needing to re-compile the kernel without the CONFIG_IP_TRANSPARENT_PROXY option if you want the JVM to run under root. This probably shouldn't be an issue for us as we run the servers as the appropriate "user" who owns the server. I haven't checked to see if there are any linux-specific concerns related to Postgres, but I'd guess that since postgres seems to be "linux first" that I wouldn't expect there would be too many issues there. Talk to you later, John From bmurray at snf.stanford.edu Mon Feb 11 09:31:41 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 11 Feb 2002 09:31:41 -0800 (PST) Subject: Draft of "CoralSetupTable" document ... In-Reply-To: <3C66D405.6CAF6589@snf.stanford.edu> Message-ID: John, I've answered your questions below. I'm still not feeling well so I'm going to take a sick day and rest. If that doesn't work, I'll have to see the doctor. Maybe it's just old age? Thanks, Bill On Sun, 10 Feb 2002, John Shott wrote: > Bill: > > I've left a copy of a Word document telling how to setup the 9 or so > datatables that we need for equipment and accounting purposes. It is in your > mailbox. I also think that the Excel files are ready to go. Am I correct in > thinking that all of the field and table names in Postgres are lowercase? > Here's how Postgres handles capitalization. This is based on experience. I haven't found anything in the documentation that explains this. CASE SENSITIVE: passwords, user names CASE INSENSITIVE: table names, field names It appears that items handle by the operating system are case sensitive, and things handle by the database engine are case insensitive. Similar to Oracle. > Also, I know that we set up the acct_rate_working and related tables so taht > we could select the proper rates dependent on the time window, use it for > "what if" analysis, etc. Am I correct in thinking that accounting_summary() > isn't yet using those. > Accounting_summary does use the rates that are in effect at the beginning of the accounting period. So we are ready to do what-if analysis. > Also, two things that we may need to consider before sending stuff to > PennState: > > 1. Do we want to add support for multiple labs at this time? > Unless they are ready to go right now, we should probably add lab. The most difficult part of this exercise is testing and modifying our existing tables. Since we have only one lab, we could decide to use the new code, but not store lab in our database. Then we wouldn't have to touch our tables. I would need to add a constant or a configuration parameter that indicates wether multiple labs are in use. If not, we could just ignore lab. The activity dialog box would not display it and the adapter wouldn't store it in the database. It could be very configurable. However, if a site added another lab later, the configuration variable or constant would have to be set to the new value, and the tables would have to be converted. > 2. Penn State charges different rates for Academic and non-Academic users. > Although I don't have it clearly thought out ... I think that we may need to > add a "type" field (industrial, local, other academic, foreign, government) to > all of the accounting tables. That should be too bad if it only needs to be done in the accounting tables. > > Also, they have a few other "non-standard" ways that they charge for > equipment. For direct-write e-beam uses they have a daily cap. If the e-beam > is being used for mask-making, however, they charge a certain amount if the > writing time is less than 16 hours and a different fixed amount if the use is > more than 16 hours. (Oh yes, and different rates depending on whether it is a > 4" or a 5" plate ... Hopefully, we can convince them to move to a time-based > system. This is a hassle, but could be accomplished with some difficulty in the accounting script. If I'm feeling better this afternoon, I'll try and finish up the Postgres functions. Also, I think I'm really close on that bug. From bmurray at snf.stanford.edu Mon Feb 11 09:38:05 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 11 Feb 2002 09:38:05 -0800 (PST) Subject: Adding "lab" to activity Message-ID: John, As I begin to think about it, we should probably add lab to all our tables now. Even though, we have only one lab. If we don't, we would have to use a different set of accounting scripts. Bill From shott at snf.stanford.edu Wed Feb 13 10:31:27 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 13 Feb 2002 10:31:27 -0800 Subject: Coral Wish List Message-ID: <3C6AB0FF.F75A4A94@snf.stanford.edu> Bill and Mike: I've been doing a crummy job of keeping track of all of the improvements that we'd like for Coral. So, here is my first attempt to generate a working list. Hopefully, after you and some of our "customers" have had a chance to add to this list, we can begin to prioritize, assess level of effort, etc. My guess is that you'll come up with things that I've forgotten. It is clear, however, that we are in no danger of running out of things to do ... So, in no particular order: Hardware Stuff: 1. Install Solaris machines, including RAID disks, SunRay failover, etc. (Well, this includes software stuff as well ... Oracle 8.1.7, etc.) 2. Get faster Linux box for development effort (probably in one of the black rackmount boxes). 3. Improve firewall machines Overall Software Stuff: 1. Deploy Coral at Penn State 2. Deploy Coral at MIT 3. Deploy Coral at UCB 4. Update firewall software ... including mechanism to allow rosen to communicate through the firewall with remote clients. 5. Update daemon/driver to run under newer versions of RedHat and consider updating walker to that version. Supporting software Stuff: 1. Finish update of adjustments in monthly accounting scripts. 2. Finish sprucing up Makefiles including rsync stuff. 3. Update newuser, and set_password for rsync. 4. Study and adopt "report generation" strategy ... ideally an affordable, commecial means of generating Excel files from our database with "pre-canned" queries. Predominantly Server Side Stuff: 1. "Configuration manager" capabilities with more parameters coming from the DB (where possible). 2. Admin manager update to start/stop other servers. 3. Admin manager monitoring of performance statistics. 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 ...) 2. Come up with a way of displaying all reservations for a given person on a signle GUI panel. 3. On history panel, add "red" and "yellow" shading for problem/shutdown periods. 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 2. Recipe Client/Server 3. Think about and implement "more than one lab" capability. 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 ... Let me know if you have additions to this list or don't understand what I mean by some of these items. Thanks, John From mbell at snf.stanford.edu Wed Feb 13 11:08:18 2002 From: mbell at snf.stanford.edu (Mike Bell) Date: Wed, 13 Feb 2002 11:08:18 -0800 Subject: Coral Wish List References: <3C6AB0FF.F75A4A94@snf.stanford.edu> Message-ID: <3C6AB9A2.C9268E7B@snf.stanford.edu> Looks good. I'm guessing that our supplier of Walker cards is still in business or do we need to address a replacemnet once sites begin wanting to deploy inerlocks? Mike John Shott wrote: > Bill and Mike: > > I've been doing a crummy job of keeping track of all of the improvements that > we'd like for Coral. So, here is my first attempt to generate a working > list. Hopefully, after you and some of our "customers" have had a chance to > add to this list, we can begin to prioritize, assess level of effort, etc. My > guess is that you'll come up with things that I've forgotten. It is clear, > however, that we are in no danger of running out of things to do ... > > So, in no particular order: > > Hardware Stuff: > > 1. Install Solaris machines, including RAID disks, SunRay failover, etc. > (Well, this includes software stuff as well ... Oracle 8.1.7, etc.) > > 2. Get faster Linux box for development effort (probably in one of the black > rackmount boxes). > > 3. Improve firewall machines > > Overall Software Stuff: > > 1. Deploy Coral at Penn State > > 2. Deploy Coral at MIT > > 3. Deploy Coral at UCB > > 4. Update firewall software ... including mechanism to allow rosen to > communicate through the firewall with remote clients. > > 5. Update daemon/driver to run under newer versions of RedHat and consider > updating walker to that version. > > Supporting software Stuff: > > 1. Finish update of adjustments in monthly accounting scripts. > > 2. Finish sprucing up Makefiles including rsync stuff. > > 3. Update newuser, and set_password for rsync. > > 4. Study and adopt "report generation" strategy ... ideally an affordable, > commecial means of generating Excel files from our database with "pre-canned" > queries. > > Predominantly Server Side Stuff: > > 1. "Configuration manager" capabilities with more parameters coming from the > DB (where possible). > > 2. Admin manager update to start/stop other servers. > > 3. Admin manager monitoring of performance statistics. > > 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 ...) > > 2. Come up with a way of displaying all reservations for a given person on a > signle GUI panel. > > 3. On history panel, add "red" and "yellow" shading for problem/shutdown > periods. > > 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 > > 2. Recipe Client/Server > > 3. Think about and implement "more than one lab" capability. > > 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 ... > > Let me know if you have additions to this list or don't understand what I mean > by some of these items. > > Thanks, > > John From bmurray at snf.stanford.edu Wed Feb 13 21:29:23 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 13 Feb 2002 21:29:23 -0800 (PST) Subject: Activity Summary Bug Fix Message-ID: John, I finally found and fixed the activity summary bug for removing tallies for adjustments. However, after looking at the code for so long, I decided the old (and now fixed) approach was very inefficient and time-consuming. So I simplified the mechanism. I have checked-in and compiled the new procedure on rosen. I was hoping you could re-run February's numbers to confirm that I had fixed the problem. Also, more importantly, confirm that I didn't break anything else. The second problem you identified on pcastle's January charges was an equipment enable for 202,769 minutes (over 140 days) which did not get adjusted. My code for making adjustments does not adjust any entries that exceed 144,000 minutes (100 days). I do this in a number of places for safety and efficiency reasons. For example, I don't attempt to display in history any entry that exceeds 100 days. (At the time I coded this, I thought any entry that long should be adjusted manually.) I can increase this number if you wish, but I really should place some upper limit on these queries. It's a quick change. Let me know if you want it changed. But for now, you will still see pcastle's balzer enable of 202,769 minutes under the defunct project/account 2FEH702. Thanks, Bill From bmurray at snf.stanford.edu Wed Feb 13 21:34:34 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 13 Feb 2002 21:34:34 -0800 (PST) Subject: Status Message-ID: John, I *think* I'm close to finishing up the PostgreSQL functional equivalents of the Oracle stored procedures. First thing tomorrow, I'll start testing. As soon as I finish up, I'll give you a call so we can discuss what's next on the list. I've promised Mike that I would install Oracle once he has the new server ready. I think that he may be quite close. Bill From shott at snf.stanford.edu Thu Feb 14 10:06:04 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 14 Feb 2002 10:06:04 -0800 Subject: [Fwd: please check corl it is logging history into the FUTURE!] Message-ID: <3C6BFC8C.33BA8377@snf.stanford.edu> Bill: It does appear that there is something funny going on with the history client under semhitachi. It shows multiple events for tombler (even into the future ... later today) that all appear to be the same event duplicated a bunch of times (and placed in the wrong time slot). I don't know whether this is a result of the very long (6 day) use that jwc had the previous 6 days ... but it does appear to have uncovered some sort of a bug. Thanks, John -------------- next part -------------- An embedded message was scrubbed... From: James Conway Subject: please check corl it is logging history into the FUTURE! Date: Thu, 14 Feb 2002 09:19:56 -0800 Size: 1326 URL: From bmurray at snf.stanford.edu Sat Feb 16 01:13:51 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 16 Feb 2002 01:13:51 -0800 (PST) Subject: ActivityArray bug Message-ID: John, I finally found and fixed the bug which James Conway pointed out in the case of tombler on the semhitachi history. I have not had a chance to test the changes which were a little tricky. Since ActivityArray is used everywhere in the client, I do need to test this carefully. It shouldn't take long. I have checked the changes into the repository so I don't loose track of them. However, I have not checked them out on rosen and will not until I have finished testing. Thanks, Bill From bmurray at snf.stanford.edu Mon Feb 18 16:51:43 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 18 Feb 2002 16:51:43 -0800 (PST) Subject: Bug Fix Tested & Installed Message-ID: John, I tested the bug fix for ActivityArray and installed the new clients on sunray and on snf for the remote version. To fix the bug, I had to change the algorithm for displaying history data. I believe the new approach is better than the old one. (It's certainly no worse.) Take a look and see what you think. We can discuss the details on Tuesday. Thanks, Bill From bmurray at snf.stanford.edu Wed Feb 20 13:28:44 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 20 Feb 2002 13:28:44 -0800 (PST) Subject: have time to talk? (fwd) Message-ID: John and Mike, Here's a copy of an email from Tom sent to me. You should probably read his email at the bottom before my response at the top. Bill ---------- Forwarded message ---------- Date: Wed, 20 Feb 2002 13:25:44 -0800 (PST) From: Bill Murray To: Thomas Lohman Cc: Bill Murray Subject: Re: have time to talk? Tom, That's great. I'm glad to hear that Ike accpted the job. We need to make sure that we get started with co-development from the start of his tenure. To be honest, I'm not sure I know the best way to do this. I think the best way is to make sure that we (MIT, Stanford, UCB) have a well-defined list of priorities to work from. Then we will want to do the analysis and design up front so that all interested parties can review the specifications. Finally, I think that the testing of any new code should be done by developers at a different site to make sure that the code really does meet the specs. We are willing to work with the student, but we are quite gun-shy. Vicky needs to understand that I threw out 70,000 lines of code written by very talented masters students here at Stanford. Then Troy and I worked incredible hours to rewrite everything. Unlike Vicky, I was actually attempting to direct their work and still failed. So I think we have to have everything in writing. We're more than happy to work on it, but the first step is for MIT to describe in writing exactly what they think the recipe manager should do. Then, we (Stanford and UCB) will review that analysis work. At that point, I think we can all get started, but MIT has to take the first step. Just tell us what you guys think it should do: a 5-page written description without any design stuff or attempts to fit it with the existing Coral. Yes, we do have everything running on RH 7.x. I don't have any notes on setting up the OS itself. However, I do have notes on how to set up PostgreSQL and Coral once Linux is installed. You can find the notes in the CVS repository in labnet/sql/postgres/README. You should read these notes first because ideally you will want to create a separate partition where you'll mount /usr/local/coral or /usr/local/coral/data. I'm tied up today with an urgent task and tomorrow I'm going to an Oracle User's Group conference at Oracle. However, I'm available all day Friday. What time would you like to talk on Friday? Thanks, Bill On Wed, 20 Feb 2002, Thomas Lohman wrote: > Bill, do you have some time to talk? We've made an offer to Ike Lin and he > accepted and is starting next Thursday. We'll need to start discussing what > to get him going on besides just general installation work here with me. I > definitely want this to be a co-development environment with you guys. > > I think we also need to discuss the recipe mgr needs. I don't want the > masters student that Vicky hired to go off and do something totally useless. > I know you guys feelings on whether he should have been hired but at this > point that's moot unfortunately. > > Also, I need to talk to you about whether you have the RH 7.x setup going and > if you have any notes, etc for it. I have a RH 7.x box setup for the masters > student and its ready to go for his own dedicated development environment. > > thanks, > > > --tom > From shott at snf.stanford.edu Fri Feb 22 09:25:55 2002 From: shott at snf.stanford.edu (John Shott) Date: Fri, 22 Feb 2002 09:25:55 -0800 Subject: [Fwd: coral problem] Message-ID: <3C767F23.7ED6317D@snf.stanford.edu> Bill and Mike: I've just done a servers restart to resolve this ... that was a pretty long run between restarts. John -------------- next part -------------- An embedded message was scrubbed... From: Lian Zhang Subject: coral problem Date: Fri, 22 Feb 2002 09:18:42 -0800 (PST) Size: 973 URL: From bmurray at snf.stanford.edu Fri Feb 22 16:22:47 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 22 Feb 2002 16:22:47 -0800 (PST) Subject: [Fwd: proposal] (fwd) Message-ID: ---------- Forwarded message ---------- Date: Fri, 22 Feb 2002 16:20:32 -0800 (PST) From: Bill Murray To: Thomas Lohman Subject: Re: [Fwd: proposal] Tom, This proposal represents man-years of effort. I think he needs to significantly narrow the scope. Here might be something realistic. 1) How do we represent a process step using XML? Take an actual process in the MIT lab and define an XML document to represent it. Then attempt to extend this to a generic process. Can XML Schema be used to do this? How? 2) Assuming we have defined an XML document or schema to represent a process step, how do we design an interface to collect the data? Can we use one general purpose interface built from the XML Schema? We certainly can't write a new interface for every process step. He could then write a prototype GUI that is generated from the XML Schema. This would be really pretty cool and useful. 3) What's the best way to store the XML documents representing process steps. Ideally, we would like to store these documents in any relational database. How do we search a library of XML process steps? Do we have to load the whole library into memory? These are good topics for a Master's thesis and will make a significant contribution to the process/recipe manager analysis and design. Have a great weekend, Bill On Fri, 22 Feb 2002, Thomas Lohman wrote: > From shott at snf.stanford.edu Sat Feb 23 12:40:33 2002 From: shott at snf.stanford.edu (John Shott) Date: Sat, 23 Feb 2002 12:40:33 -0800 Subject: JDK 1.4.0 ... Official Version Message-ID: <3C77FE41.F21A4EC3@snf.stanford.edu> Bill and Mike: Sun has released the production version of JDK 1.4.0. I've downloaded and installed it (including appropriate OS patches) on: guilden, rosen, and sunray. I still need to do bopeep, shott, spf, and the other solaris 8 machines. Note: in order to have the kernel updates take effect, I need to reboot guilden, rosen, and sunray. I'll hope to do rosen and sunray on Sunday a.m. when it is quiet ... Bill, is there any reason that I can't reboot guilden at that same time? Thanks, John From bmurray at snf.stanford.edu Sat Feb 23 14:08:46 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 23 Feb 2002 14:08:46 -0800 (PST) Subject: JDK 1.4.0 ... Official Version In-Reply-To: <3C77FE41.F21A4EC3@snf.stanford.edu> Message-ID: John, Please reboot guilden at the same time. Perhaps we'll get lucky, and this will fix the problem with the admin server hanging? Thanks, Bill On Sat, 23 Feb 2002, John Shott wrote: > Bill and Mike: > > Sun has released the production version of JDK 1.4.0. > > I've downloaded and installed it (including appropriate OS patches) on: > > guilden, rosen, and sunray. > > I still need to do bopeep, shott, spf, and the other solaris 8 machines. > > Note: in order to have the kernel updates take effect, I need to reboot > guilden, rosen, and sunray. I'll hope to do rosen and sunray on Sunday a.m. > when it is quiet ... Bill, is there any reason that I can't reboot guilden at > that same time? > > Thanks, > > John > From shott at snf.stanford.edu Sun Feb 24 09:13:01 2002 From: shott at snf.stanford.edu (John Shott) Date: Sun, 24 Feb 2002 09:13:01 -0800 Subject: OS upgrade update ... Message-ID: <3C791F1D.E8C03E24@snf.stanford.edu> Bill and Mike: I've rebooted sunray, rosen, and guilden. Everything looks fine on sunray and rosen ... Guilden looks fine, too. I've installed JDK 1.4.0 on spf too. However, it still is unable to mount /home from guilden ... guilden is still complaining about the "no default domain". I don't know the cause of that. Bobeep seems to have a problem ... in fact, I can't get to it it do anything (I haven't done any upgrade sutff there.). It claims to not be able to find the shell it is looking for ... I also can't even get in in single user mode. And it claims to be running out of space on /var/mail/mqueue ... or something like that. So, I'm stumped ... John From shott at snf.stanford.edu Mon Feb 25 07:34:45 2002 From: shott at snf.stanford.edu (John Shott) Date: Mon, 25 Feb 2002 07:34:45 -0800 Subject: Enable/disable problems on Saturday/Sunday? Message-ID: <3C7A5995.8951493C@snf.stanford.edu> Bill and Mike: I've received several messages about a enable/disable inconsistencies that occurred on Saturday/Sunday. If they exist, they may have become visible when I rebooted and restarted the servers on Sunday a.m. Unfortunately, it appears that I was stupid when I restarted the servers ... instead of moving the files to lastlog, I deleted them thinking that we were moving to a new JDK anyhow. Mike: can you look to see when our latest backup of /var/log/labnet/*.log occurred? If we did that either Friday night or Saturday night, it would be useful if they can be reloaded into /var/log/labnet/backup/*.log. It sort of sounds as if the database and the server were our of sync in some fashion and that when I restarted the servers, Coral didn't agree with what the hardware thought was happening. Thanks, John Here are some of the reports: Subject: weird enabling on coral Date: Sun, 24 Feb 2002 11:19:48 -0800 (PST) From: Nabeel Ibrahim To: shott at snf.Stanford.EDU Subject: WB-CTB/Coral? Date: Sun, 24 Feb 2002 22:37:22 -0800 (PST) From: "Mohammed H. Badi" To: shott at snf.stanford.edu CC: rcrane at snf.stanford.edu, uli at snf.stanford.edu, latta at snf.stanford.edu John, Was there a Coral crash of some sort on Sat/Sun? I'm asking b/c I had a critical timed etch at WB General's Controlled Temperature Bath that I started on Saturday afternoon. I checked on it on Sat night and things were okay. When I came in on Sunday evening the CTB had been disabled!! As a result the heater turned off and the timing of my etch was lost. The history on coral doesn't show me as ever having enbled the system in the first place. I did talk to someone, however, who saw that I had CTB enabled early Sun morning but then saw it disabled around 10am. I also noticed that you enabled it at 1730 on sunday. Any insight you could give me would be appreciated. Thank you. Mohammed Badi mbadi at snf -------- Mohammed H. Badi 650.906.0663 John, A bunch of equipment appears to have been mysteriously enabled since Friday morning. The equipment shows up as enabled on coral, but not on the machine. I noticed this with tylanbpsg and wbmetal and other people in the lab said they've seen it too. Nabeel Problem semhitachi 2002-02-24 14:24:42: problem with SEM Date: Feb 24, 2002 2:24:42 PM From: yenilmez at snf.stanford.edu To: semhitachi-pcs at snf.stanford.edu machine is enabled on Coral, but the green ON light is not lit. Cannot load sample. Subject: possible coral error Date: Sun, 24 Feb 2002 18:18:38 -0800 (PST) From: Lian Zhang To: shott at snf.stanford.edu Hi John, I emailed you last Friday morning about the problem that I couldn't enable the semhitachi from the terminals in CIS. I had to go back to my office and enabled it remotely. Then when I was done around 11am, I found I could loggon the terminal in the computer room and disabled the machine. However, I just heard from my friend that the machine seemed to stay enabled under my name for the entire weekend. I just checked and it's not under my name any more. So I guess either the terminal didn't work when I disabled the machine or I didn't disable it at all. But if there's a way to find out, I'd appreciate it. Otherwise I'll just be careful. Thanks! Lian From bmurray at snf.stanford.edu Tue Feb 26 09:36:01 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 26 Feb 2002 09:36:01 -0800 (PST) Subject: spf down? Message-ID: John or Mike, I can't seem to reach spf. Is it down? Thanks, Bill From bmurray at snf.stanford.edu Tue Feb 26 18:20:07 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 26 Feb 2002 18:20:07 -0800 (PST) Subject: Coral Database on spf Message-ID: John, I have the Coral database all created and ready to be loaded on spf. I don't remember where the Perl scripts are located to load the data from rosen or bopeep. I think this was a fairly substantial task that you took care of last time. I'd be happy to do it if you point me in the right direction. Of course, I found things that I left out of the original Makefile that should make things a little easier next time. I've added these and will check it in when I'm finished. I started PostgreSQL manually on spf. Since the 7.2 start-up scripts have changed, I'm still working on getting them running properly on spf. As soon as I finish that, I'm going to finish up the accounting/activity functions on spf. They compile, but still have some run-time problems. Thanks, Bill From shott at snf.stanford.edu Wed Feb 27 07:32:51 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 27 Feb 2002 07:32:51 -0800 Subject: Coral Database on spf References: Message-ID: <3C7CFC23.23F28E1A@snf.stanford.edu> Bill: I made an attempt to load some data ... I actually tried stfmgr from rosen. It appears as if there is a pg_hba.conf file on SNF that tells what machines can access it? Here is the error message: DBI->connect(dbname=lab;host=spf;port=5432) failed: FATAL 1: No pg_hba.conf entry for host 192.168.0.11, user stfmgr, database lab at ... Talk to you later, John From shott at snf.stanford.edu Wed Feb 27 09:08:40 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 27 Feb 2002 09:08:40 -0800 Subject: Coral enable/disable difficulties over the weekend .... References: <200202270607.g1R67vA25185@myth5.Stanford.EDU> Message-ID: <3C7D1298.E5EBBD9F@snf.stanford.edu> Mike: Gee, this is one that I have not encountered before. Were these both "in lab" Coral sessions, one remote and one local, or what? If you can remember the particulars of who had which timeslots reserved, this may help us to track this down ... While this is not a problem that we have seen before, it is definitely something that we need to look into. Thanks for alerting us to this... John > Hi John, > > I also ran into a situation tonight where myself and another user both reserved the same > time > slots on the Karlsuss...depending on whose Coral browser we checked. Very strange. Just > thought you would like to know. > > Mike > >