From bmurray at snf.stanford.edu Sat Mar 2 22:59:14 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 2 Mar 2002 22:59:14 -0800 (PST) Subject: Coral Running on Linux (spf) Message-ID: John, Here are the short-term fixes I made to get Coral running on spf. (I thought I had written all this down when I did shott, but I couldn't find it. This took a little while to duplicate so I'm not going to lose this one. Ouch!) Some of these symbolic links may be circular. They're probably not the correct way to do this. I believe that Coral is basically installed on spf now. However, I have some runtime issues which I believe are related to using Postgres instead of Oracle. (For example, the multiple records in the Admin Manager's status table.) I'll take a look at these first thing on Monday. Thanks, Bill 1) The makefiles look for whoami in /usr/ucb. On Linux, it's in /usr/bin. So I made a symbolic link in /usr as follows: ln -s /usr/bin ucb 2) make[2]: /usr/j2se/bin/idlj: Command not found. I changed the Makefile in labnet to reflect the location of the JDK on spf by changing JDK_BIN to /usr/java/j2sdk1.4.0/bin 3) Here is a cvs diff of the changes I had to make to the etc/Makefile. < JAVA_LIB = /app/java/lib --- > JAVA_LIB = /usr/share/pgsql 52c52 < JDBC_JAR = $(JAVA_LIB)/jdbc.zip --- > JDBC_JAR = $(JAVA_LIB)/jdbc7.1-1.2.jar 80c80 < JAVA_LIB = /app/java/lib --- > JAVA_LIB = /usr/share/pgsql 83c83 < JDBC_JAR = $(JAVA_LIB)/jdbc.zip --- > JDBC_JAR = $(JAVA_LIB)/jdbc7.1-1.2.jar 105c105 < JDK_HOME = /usr/j2se --- > JDK_HOME = /usr/java/j2sdk1.4.0 110c110 < JAVA_LIB = /app/java/lib --- > JAVA_LIB = /usr/share/pgsql 113c113 < JDBC_JAR = $(JAVA_LIB)/jdbc.zip --- > JDBC_JAR = $(JAVA_LIB)/jdbc7.1-1.2.jar 4) package javax.crypto does not exist. Copied jce.zip from rosen to /usr/java/j2sdk1.4.0/jre/lib/ext on spf. 5) Modified constants/Constants.java as follows: public final static String DATABASE = "Postgres"; 6) Modified the configuration files as follows: Client.conf.dev: IOR_DIRECTORY=http://spf.snffab.stanford.edu/ Server.conf.dev: JDBC_DRIVERNAME=Postgres JDBC_DRIVERCLASS=org.postgresql.Driver JDBC_URL=jdbc:postgresql://spf.snffab.stanford.edu:5432/lab LABNET_DB_PASSWORD=secure IOR_URL=http://spf.snffab.stanford.edu/ ORB_INITIAL_HOST=spf.snffab.stanford.edu ORB_SERVER_HOST=192.168.0.104 7) The scripts all start with #!/sbin/bash However, on Linux bash is in /bin. So I added a symbolic link in sbin as follows: ln -s /bin/bash bash 8) /usr/local/sbin/servers: /usr/ucb/ps: No such file or directory Made a symbolic link in /usr/ucb to /bin/ps as follows: ln -s /bin/ps ps From bmurray at snf.stanford.edu Sun Mar 3 00:38:26 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sun, 3 Mar 2002 00:38:26 -0800 (PST) Subject: Coral Servers Running!!!! Message-ID: John, All the servers are up on spf and appear to be running great. Of course, I cannot run the client from home since spf is behind the firewall. All the remaining problems were configuration problems. No problems at all with PostgreSQL. We may need to make some changes to the kernel on spf to support Coral and the JVM. I have a list of the recommended kernel changes in my office. You can give the clients a try when you're ready. I believe I have Client.conf.dev set up properly. Here's a list of the final adjustments I had to make to get everything running: The problem with multiple status records was a side-effect of loading data from the status table on rosen. Once I deleted all the status records loaded from rosen, the admmgr created correct ones. Since Apache is configured with a document directory of /var/www/html I made a symbolic link there to the AdminServerIOR as follows: ln -s /home/labnet/share/IOR/AdminServerIOR AdminServerIOR Also, the httpd was not being started when spf booted so I manually started httpd. I created the required directories in /etc/coral as follows: (One could do the chmod and chown recursively, but I needed the practice typing.) [root at spf etc]# pwd /etc [root at spf etc]# mkdir coral [root at spf etc]# chmod 770 coral [root at spf etc]# chown auth coral [root at spf etc]# cd coral [root at spf coral]# mkdir certs [root at spf coral]# mkdir private [root at spf coral]# chmod 770 * [root at spf coral]# chown auth * [root at spf coral]# cd private [root at spf private]# mkdir shadow [root at spf private]# chmod 770 shadow [root at spf private]# chown auth shadow Once these directories were created, the athmgr properly noted that the private key file could not be found and generated a new public/private key pair. Finally, I tried to do a "make remote-install". Got the following error: [root at spf labnet]# make remote-install /app/jdk/bin/java -DFILEOUT=/var/log/labnet/zkm/ZKMConversions.log \ -DJAR_FILE_IN=lib/coral.jar -DSAVE_DIR=lib/obfuscated -DZKM_JAR=/app/solaris/2.6/zkm/ZKM.jar \ -classpath /app/solaris/2.6/zkm/ZKM.jar ZKM -v \ -l /var/log/labnet/zkm/ZKM.log config/script_zkm.txt make: /app/jdk/bin/java: Command not found make: *** [lib/obfuscated/coral.jar] Error 127 I modified the Makefile to use $(JDK_BIN) instead of /app/jkd/bin. I can't check this in because I have too many changes to the Makefile that shouldn't go in the repository. Next error: FATAL ERROR: Invalid classpath in "classpath" statement at line 7 : /usr/j2se/jre/lib/rt.jar is not a valid path. I think I'm too tired to find this one. It looks like we still have a few minor issues left before we can do a remote-install like the error above. Also, we may have difficulty signing our jars related to the keystore password. I also noticed that when the athmgr created the private key in .keystore, the .keystore was world-readable. Please remind me to modify the code to set the permissions properly because other schools won't even know the file exists. I went ahead and changed the permissions manually on the spf copy. Good night, Bill From bmurray at snf.stanford.edu Sun Mar 3 00:51:43 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sun, 3 Mar 2002 00:51:43 -0800 (PST) Subject: Transaction Isolation Level Message-ID: John, I was just checking the logs on spf before heading to bed, I noticed we have our first problem related to PostgreSQL. The admmgr log had the following error: java.sql.SQLException: ERROR: SET TRANSACTION ISOLATION LEVEL must be called be fore any query However, the admmgr responded gracefully by rolling back the transaction. I'll have to look at the spec, but my guess is this may be a place where PostgreSQL actually adheres to the SQL spec more closely than Oracle. I'll take a look on Monday. I'm going to leave the servers up and running in case you want to run the client. This problem may prevent you from doing much testing, and/or the logs may get large? Bill From bmurray at snf.stanford.edu Sun Mar 3 22:49:54 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sun, 3 Mar 2002 22:49:54 -0800 (PST) Subject: It's Happening Message-ID: John, I took Miranda and a friend to the beach today and didn't get home until about 8pm. I checked the logs then and noticed that problems began at about 12:30pm today with transaction 20796 which never completed. The clients can still start, but there have been no heartbeats recorded in the database since this time. I've been tracking down the problem for the last few hours. I'm still looking. We've had other problems from the moment we started the servers. I don't know how I missed these few lines in the admmgr log: java.lang.NoSuchMethodError: labnet.admin.server.AdminManagerImpl.updateStatus(L labnet/corba/StatusInfoAdapter;)V at labnet.admin.server.AgentMonitor.tryCleaning(AgentMonitor.java:332) at labnet.admin.server.AgentMonitor.run(AgentMonitor.java:139) What this means is that we have old and new code running in the production version of the admin manager. The AgentMonitor appears to be using a an updateStatus signature that doesn't exist. The compiler should have picked this up. So I suspect there may be a dependency that Troy and I didn't capture in the makefiles. A clean make should help me find this one. However, this is complicating my search for the "real" problem because this error appears to mean that the AgentMonitor hasn't been running. I'll keep searching. At some point, this evening I'll probably have to move the logs and restart everything. I would like to watch and see what eventually causes everything to stop although I may have enough info to track this down now. Bill From bmurray at snf.stanford.edu Mon Mar 4 01:11:28 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 4 Mar 2002 01:11:28 -0800 (PST) Subject: Latest Theory Message-ID: John, Remote users have been able to access Coral until I restarted the servers a few minutes ago. However, local users lost access to coral around 12:36 this afternoon. I've spent the last few hours looking at the database tables and logs before I restarted the servers. Without going into all the details, I believe that the admin manager's JDBC connection to the database hung at about 12:30pm today. Since each manager has a single JDBC connection to the database, this ultimately results in the failure of the manager. I need to find a way to confirm my hypothesis. Then I can evaluate the two possible solutions. We could use a connection pool which presents some tricky technical issues in our architecture. Or we could consider options for periodically opening a new connection to the database or attempting to detect connection failures and opening a new connection. I'll sleep on this one and talk to you in the morning. Thanks, Bill From bmurray at snf.stanford.edu Mon Mar 4 01:21:15 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 4 Mar 2002 01:21:15 -0800 (PST) Subject: Ancient JDBC Driver? Message-ID: John, I haven't ever upgraded our JDBC driver. This probably means that we're still running with a JDBC driver I downloaded from the Oracle web site over 4 years ago? The first thing we should do tomorrow morning is check the JDBC driver vintage and download a new one from the Oracle web site. The Oracle CDs come with JDBC drivers that were current as of that release of Oracle. However, the JDBC drivers tend to be updated quite frequently. Good night, Bill From bmurray at snf.stanford.edu Tue Mar 5 13:59:34 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 5 Mar 2002 13:59:34 -0800 (PST) Subject: CVS user/password In-Reply-To: <5.1.0.14.0.20020305155147.00a6a2a8@mtl.mit.edu> Message-ID: Ike, That's no problem. I'll set up accounts for both of you. (Ask Tom if he would like his own account also.) For read-only access, we are using CVS password authentication. For write-access, we are using SSH which requires the developer to have a Unix account on the machine where the repository resides and write access to the files. Until we create some new groups and resolve permission issues on our repository machine, I'll give you read-access using CVS password authentication. Since the CVS password authentication is weak anyway, why don't you call my voice mail box and leave your login names and passords at 650-725-3639? (Clearly you don't want to choose a password you're using for anything sensitive elsewhere.) I'll set up your accounts immediately and email you when they're ready. Here are brief notes on how to get going (which I believe should answer all your questions). 1) Make sure that cvs is installed on your machine. 2) Set the CVSROOT environment variable. Depending on your shell, something like this: export CVSROOT=:pserver:your_login_name at snf.stanford.edu:/home/src 3) At the prompt, type "cvs login". You will be prompted for the password. (You will only need to type cvs login the first time, then the password is stored insecurely on your machine.) 4) cd to the directory where you want to place the Coral source. Then type "cvs checkout labnet". This will checkout a complete copy of the source repository by creating a directory named "labnet" in the current directory. This will be the most current version of the source. 5) In the future, when you wish to get updates, you can get the latest code in the repository by typing "cvs update -d". If you have any problems or questions, give me a call at (650) 725-3639. Thanks, Bill On Tue, 5 Mar 2002, Ike Lin wrote: > Bill, > > Can you setup such that both Jeff and I can access the CVS repository at > Stanford? It would be nice if we can both have our own account (so you'll > know who's messing with your code :P). If that's too much trouble, at > least give us the account that Tom has. We need (or for you to confirm) > the following information : > > 1. is CVSROOT ":pserver:coral at snf.stanford.edu:/home/src"? > 2. What authentication are we using? ".rhost" file or "passwd" file or SSH > server? > 3. module name > 4. user id/password > > Thanks, > Ike > From thomasl at mtl.mit.edu Tue Mar 5 14:02:58 2002 From: thomasl at mtl.mit.edu (Thomas Lohman) Date: Tue, 05 Mar 2002 17:02:58 -0500 Subject: CVS user/password References: Message-ID: <3C854092.CCDF8080@mtl.mit.edu> (Ask Tom if he > would like his own account also.) Yes, definitely. I will call you and leave a username/password. From mtang at snf.stanford.edu Thu Mar 7 11:04:39 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Thu, 07 Mar 2002 11:04:39 -0800 Subject: Coral Cards Message-ID: <3C87B9C7.53796A85@snf.stanford.edu> Hello gentlemen -- There are no more Coral cards by the gowning room entrance (aside from a couple "dead" ones). And, there really don't seem to be too many people in the lab -- so, I guess these cards somehow evolve legs and walk away. Do you fellows have any more in stock? Mary -- Mary X. Tang, Ph.D. National Nanofabrication Users' Network Stanford Nanofabrication Facility CIS Room 136, Mail Code 4070 Stanford, CA 94305 (650)723-9980 mtang at snf.stanford.edu From mbell at snf.stanford.edu Thu Mar 7 11:11:05 2002 From: mbell at snf.stanford.edu (Mike Bell) Date: Thu, 07 Mar 2002 11:11:05 -0800 Subject: Coral Cards References: <3C87B9C7.53796A85@snf.stanford.edu> Message-ID: <3C87BB49.7B199691@snf.stanford.edu> I'll give another 25 to Lourdes. I have noticed that we seem to be losing them at a faster rate. We have another 100 cards in reserve. Mike Mary Tang wrote: > Hello gentlemen -- > > There are no more Coral cards by the gowning room entrance (aside from a > couple "dead" ones). And, there really don't seem to be too many people > in the lab -- so, I guess these cards somehow evolve legs and walk > away. Do you fellows have any more in stock? > > Mary > > -- > Mary X. Tang, Ph.D. > National Nanofabrication Users' Network > Stanford Nanofabrication Facility > CIS Room 136, Mail Code 4070 > Stanford, CA 94305 > (650)723-9980 > mtang at snf.stanford.edu From niblock at analatom.com Thu Mar 7 13:08:09 2002 From: niblock at analatom.com (Trevor Niblock) Date: Thu, 7 Mar 2002 13:08:09 -0800 Subject: no remote access Message-ID: Hi, I've been using coral remote with no problems for the last four months and now its died. Is it coral or my end? My user name is Trevor. Thanks Trevor. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Trevor Niblock (Ph.D, MRes(MSc),BEng), ANALATOM Inc., 540 Weddell Drive, Suite # 9 Sunnyvale, CA, 94089, USA. TEL; (408) 734 9392 FAX; (408) 734 8335 Email; niblock at analatom.com URL: http://analatom.com/ This message is confidential. It may also be privileged or protected by other legal rules. It does not constitute an offer or acceptance of an offer, nor shall it form any part of a legally binding contract. If you have received this communication in error, please let us know by reply then destroy it. You should not use, print, copy the message or disclose its contents to anyone. E-mail is subject to possible data corruption, is not secure, and its content does not necessarily represent the opinion of this Company. No representation or warranty is made as to the accuracy or completeness of the information and no liability can be accepted for any loss arising from its use. This e-mail and any attachments are not guaranteed to be free from so-called computer viruses and it is recommended that you check for such viruses before down-loading it to your computer equipment. This Company has no control over other websites to which there may be hypertext links and no liability can be accepted in relation to those sites. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -------------- next part -------------- A non-text attachment was scrubbed... Name: Trevor Niblock.vcf Type: text/x-vcard Size: 568 bytes Desc: not available URL: From bmurray at snf.stanford.edu Thu Mar 7 15:10:32 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 7 Mar 2002 15:10:32 -0800 (PST) Subject: no remote access In-Reply-To: Message-ID: Trevor, I don't see any problems at this end. Bill On Thu, 7 Mar 2002, Trevor Niblock wrote: > Hi, I've been using coral remote with no problems for the last four months > and now its died. Is it coral or my end? > > My user name is Trevor. > > Thanks > > Trevor. > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > Trevor Niblock (Ph.D, MRes(MSc),BEng), > ANALATOM Inc., 540 Weddell Drive, Suite # 9 > Sunnyvale, CA, 94089, USA. > TEL; (408) 734 9392 > FAX; (408) 734 8335 > Email; niblock at analatom.com > URL: http://analatom.com/ > > This message is confidential. It may also be privileged or protected by > other legal rules. It does not constitute an offer or acceptance of an > offer, nor shall it form any part of a legally binding contract. If you have > received this communication in error, please let us know by reply then > destroy it. You should not use, print, copy the message or disclose its > contents to anyone. E-mail is subject to possible data corruption, is not > secure, and its content does not necessarily represent the opinion of this > Company. No representation or warranty is made as to the accuracy or > completeness of the information and no liability can be accepted for any > loss arising from its use. This e-mail and any attachments are not > guaranteed to be free from so-called computer viruses and it is recommended > that you check for such viruses before down-loading it to your computer > equipment. This Company has no control over other websites to which there > may be hypertext links and no liability can be accepted in relation to those > sites. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > From bmurray at snf.stanford.edu Fri Mar 8 22:48:54 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 8 Mar 2002 22:48:54 -0800 (PST) Subject: Coral Servers Restarted Message-ID: John, The admin server hung at about 9:17pm this evening. We had been quite busy with 22,300 transactions in less than 34 hours. It still appears that the JDBC driver is hanging after a large number of transactions. Based on three failures so far that number has been 24000, 46037, and 22300. Fortunately, I noticed the problem before members had been locked out for long and restarted the servers. Although I did not find any JDBC book that was recent enough or comprehensive enough at the Stanford Bookstore, I did find a nice O'Reilly book on PostgreSQL. I'm still looking at the on-line JDBC spec and considering our options. At this point, I think the best approach may be to continue to store all booleans as integers (0 or 1) in the database. This will allow us to keep attribute types and stored procedures/functions consistent across databases. I believe it will require a few lines of change in one class, and this code will then work with any database that has a JDBC driver regardless of how they choose to store booleans. (Basically, we will aim for the lowest common denominator (Oracle) by forcing all booleans to be stored as integer zeros or ones.) Bill From mtang at snf.stanford.edu Mon Mar 11 19:23:45 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Mon, 11 Mar 2002 19:23:45 -0800 Subject: Coral down... Message-ID: <3C8D74C0.FDFC6A04@snf.stanford.edu> Help!!! Coral is down. Mary -- Mary X. Tang, Ph.D. National Nanofabrication Users' Network Stanford Nanofabrication Facility CIS Room 136, Mail Code 4070 Stanford, CA 94305 (650)723-9980 mtang at snf.stanford.edu From bmurray at snf.stanford.edu Mon Mar 11 22:53:18 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 11 Mar 2002 22:53:18 -0800 (PST) Subject: Coral down... In-Reply-To: <3C8D74C0.FDFC6A04@snf.stanford.edu> Message-ID: Mary, I got home at 8pm and noticed that Coral was having problems and restarted the servers. Just to let you know, I have located the problem. It's not in the Coral code, it's in the database driver that we're using. However, I can modify our code to work around the problem. I'll do that tomorrow. Hopefully, that will end this spate of Coral failures. Bill On Mon, 11 Mar 2002, Mary Tang wrote: > Help!!! Coral is down. > > Mary > > -- > Mary X. Tang, Ph.D. > National Nanofabrication Users' Network > Stanford Nanofabrication Facility > CIS Room 136, Mail Code 4070 > Stanford, CA 94305 > (650)723-9980 > mtang at snf.stanford.edu > > From bmurray at snf.stanford.edu Mon Mar 11 22:59:27 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 11 Mar 2002 22:59:27 -0800 (PST) Subject: Status Message-ID: John, I've built a new kernel on spf. However, I'm still having some difficulty with the installation of the new kernel. Are we using GRUB or LILO on spf? Also, the admin manager hung after 26,639 transactions. I can't take it anymore. This is humiliating. For starters, I'm going to modify the persistence layer to close the JDBC connection and open a new connection after 10,000 transactions. This costs very little and is probably a good idea under any circumstance. Bill From bmurray at snf.stanford.edu Tue Mar 12 16:30:34 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 12 Mar 2002 16:30:34 -0800 (PST) Subject: Status Message-ID: John, I'm still working on the code to reset the JDBC connection. I'm close to finishing and should have it installed tonight. As usual, it's a little trickier than I anticipated. As soon as I finish this, I'll return to the kernel installation on spf. The "make install" appears to be failing because it can't find lilo.conf which I suspect is related to the fact that we're using GRUB. Will try to get this done tonight cause I'm afraid that Mahnaz's machine will take up most of tomorrow. The setup shouldn't take long. Since there's appears to be corruption (due to a virus?), I only want to move the things she needs to the new machine. This may take some time. Bill From bmurray at snf.stanford.edu Wed Mar 13 00:50:35 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 13 Mar 2002 00:50:35 -0800 (PST) Subject: Found Bug Message-ID: John and Mike, It turns out that resetting the JDBC connection without restarting the servers is extremely difficult in our application. However, as I was attempting to make this change, I found a bug which certainly could be causing the problem we've been seeing. It's been in my persistence layer since I wrote it in 1999. It just takes a really heavy load to expose the problem (and impatient users that start multiple Coral sessions quickly). I believe I have fixed the bug, but there are a few other code segments that I should also check for any related problems. I have installed the fix on rosen with the debugging output still included. I restarted the servers a few minutes ago. Let's see if this fixes the problem. Bill PS Given the complexity of resetting the JDBC connection, we may not wish to do this if the bug fix resolves the problem. If we do wish to proceed with this, it might safer just to restart the servers periodically. PPS If I can hide from Mahnaz until tomorrow afternoon, I would like to review a couple of other code segments tomorrow morning. My short todo list: 1) Confirm that I got the bug. 2) Install new kernel on spf. 3) Finish converting stored procedures to PostgreSQL functions. 4) Set up Mahnaz's new machine. From shott at snf.stanford.edu Wed Mar 13 08:25:04 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 13 Mar 2002 08:25:04 -0800 Subject: Found Bug References: Message-ID: <3C8F7D5F.BFA5920E@snf.stanford.edu> Bill: That is excellent news ... do you think that it still makes sense to insall the new JDBC driver? OR do you want to do some testing with the otiginal one? I think that I've finished with a number of the Makefile changes. Included are: 1. I've got it setup so that it will now copy (using rysnc) the appropriate client stuff to anything defined as a SLAVE ... in production, rosen is the MASTER and sunray (and soon sunstar) will be slaves. In other words, the master runs both clients and servers and the slave only runs clients. 2. It will also (again using rysnc) install the remote stuff in the proper location when you say "make remote-install". 3. We can now run multiple development machines ... each with a separate "extension". For example, I currently have guilden as MASTER and bopeep as slave as a development version with a suffix of "-dev". Then I also have set up so that spf is a master and shott is a slave with another development version known as "-linux". In these cases, an install sets up all of its jar files as *-dev.jar, its conf file as *-dev.conf etc. Also, its "scripts" such as servers, server_start, and coral are installed as servers-dev, coral-dev, etc. If a machine does not have a production version running on it then there is a link made so that servers points to servers-dev, etc. So, when you get in and have a chance, maybe we can get this stuff tested and committed in the repository. My guess is that there are a handful of Makefiles that you have adjusted so we'll need to be careful to get a proper set installed. Talk to you later, John From bmurray at snf.stanford.edu Wed Mar 13 09:38:02 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 13 Mar 2002 09:38:02 -0800 (PST) Subject: JDK 1.4 JCE (fwd) Message-ID: John, I'm just now getting up to check the logs on rosen and spf. It's too early to tell on rosen, but things look good. The really good news is that the errors we kept getting on spf are now gone. The error was quite different than what we saw on rosen, but I believe it was a manifestation of the same problem. If you're interested, you can compare the admmgr logs on spf in /var/log/labnet and /var/log/labnet/lastlog. Let's not worry about updating the JDBC driver on rosen. I actually no longer believe that's the problem. We'll install the latest one when we move to the new hardware. Finally, I got the following message from Ike this morning. If you get a chance to respond before I arrive that would be great. Otherwise, I'll respond when I arrive. I've got to eat and clean up so I'll be a little late getting into the office. Bill ---------- Forwarded message ---------- Date: Wed, 13 Mar 2002 10:31:36 -0500 From: Ike Lin To: Bill Murray Subject: JDK 1.4 JCE Hi Bill, Thanks for setting up the CVS accounts for all of us here at MIT. We've checked out the code and run build successfully although we didn't tweak any of the site specific files. We're now in the process of setting up the database and trying to do make install. Got a question that I hope you can answer for me: We're using JDK1.4 which now requires third party AuthProvider to be signed. Is "au.net.aba.crypto.provider.ABAProvider" in the process of getting a signed version? Now we just get java.security.NoSuchProviderException: No such provider: ABA exception. Thanks, Ike From mtang at snf.stanford.edu Wed Mar 13 14:41:49 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Wed, 13 Mar 2002 14:41:49 -0800 Subject: Minor wafersaw anomoly Message-ID: <3C8FD5AD.5D043567@snf.stanford.edu> Hello Coral development team -- This is weird. I'm trying to get the history of the wafersaw, and it's largely blank, at least for the past week. But I know for certain that it's been getting a lot of use these days -- I enabled it yesterday to train people. Am I totally clueless? (I'm trying to find out who used it before 'dong' -- it's someone with a wrist of iron... I'm going to contact the people who had it reserved, presuming they are most likely to have recently used it.) Just wanted to share my weird experience with you -- Mary -- Mary X. Tang, Ph.D. National Nanofabrication Users' Network Stanford Nanofabrication Facility CIS Room 136, Mail Code 4070 Stanford, CA 94305 (650)723-9980 mtang at snf.stanford.edu From bmurray at snf.stanford.edu Wed Mar 13 19:11:19 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 13 Mar 2002 19:11:19 -0800 (PST) Subject: Minor wafersaw anomoly In-Reply-To: <3C8FD5AD.5D043567@snf.stanford.edu> Message-ID: Mary, You won the lottery. Like a blue moon, this bug can only be see on very rare occassions. You couldn't see it yesterday and you wouldn't be able to see it tomorrow. However, John and I were able to track it down and fix it. Unfortunately, you will only be able to see the fix if you look at history before midnight tonight cause this bug disappears then. Thanks for pointing this out, John and Bill On Wed, 13 Mar 2002, Mary Tang wrote: > Hello Coral development team -- > > This is weird. I'm trying to get the history of the wafersaw, and it's > largely blank, at least for the past week. But I know for certain that > it's been getting a lot of use these days -- I enabled it yesterday to > train people. Am I totally clueless? (I'm trying to find out who used > it before 'dong' -- it's someone with a wrist of iron... I'm going to > contact the people who had it reserved, presuming they are most likely > to have recently used it.) > > Just wanted to share my weird experience with you -- > > Mary > > -- > Mary X. Tang, Ph.D. > National Nanofabrication Users' Network > Stanford Nanofabrication Facility > CIS Room 136, Mail Code 4070 > Stanford, CA 94305 > (650)723-9980 > mtang at snf.stanford.edu > > From mtang at snf.stanford.edu Thu Mar 14 12:23:59 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Thu, 14 Mar 2002 12:23:59 -0800 Subject: Coral down Message-ID: <3C9106DF.28A463BB@snf.stanford.edu> Hi guys -- You are probably receiving many of these messages, but just in case people have neglected to inform you, here's another one... Mary -- Mary X. Tang, Ph.D. National Nanofabrication Users' Network Stanford Nanofabrication Facility CIS Room 136, Mail Code 4070 Stanford, CA 94305 (650)723-9980 mtang at snf.stanford.edu From bmurray at snf.stanford.edu Thu Mar 14 12:26:49 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 14 Mar 2002 12:26:49 -0800 (PST) Subject: Argh...... Message-ID: John, Although the bug I fixed Wednesday evening appears to have fixed the problem we were seeing with PostgreSQL application servers, it doesn't appear to have fixed the problem we're seeing on rosen. I'm back to looking at the code again. Thanks, Bill From mbell at snf.stanford.edu Fri Mar 15 08:14:36 2002 From: mbell at snf.stanford.edu (Mike Bell) Date: Fri, 15 Mar 2002 08:14:36 -0800 Subject: snf Message-ID: <3C921DEC.102CBCFF@snf.stanford.edu> I ran a full backup of snf last night - so today would be a great time to take a look and get rid of anything that looks old. Keep in mind that restoring from tape would take a while and there can always be a problem with open files so don't get too wild. Snf is up in the 90%+ range and I noticed it was running fairly slowly so now would be a great time to take action. The backup tape is labeled "special-snf". Mike From bmurray at snf.stanford.edu Mon Mar 18 00:39:33 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 18 Mar 2002 00:39:33 -0800 (PST) Subject: Additional Logging Message-ID: John and Mike, I'm closing in on the bug. The logs from Friday were quite helpful since the problem occurred multiple times. I've added some additional debugging output. If the problem occurs before I arrive on Monday, please call me at home so I can check the logs and the database. If you can't reach me (I'm in transit), then just restart the servers. This will preserve the logs. Thanks, Bill From mtang at snf.stanford.edu Mon Mar 18 11:51:56 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Mon, 18 Mar 2002 11:51:56 -0800 Subject: Email Lists Message-ID: <3C96455C.927159D8@snf.stanford.edu> Hello Coral Dev Team -- I know I've asked you this before, but seem to have misplaced your email reply (sorry.) What are the best ways to subscribe and unsubscribe from the various email lists? I've noticed that when I'm looking at the archived emails that the menu bars offer the option to "eSubscribe" for whatever list I'm viewing. Is this the most convenient way to subscribe to the email list? Does this mean that people can have different email addresses on file on the equipment email list from their Coral forwarding address? Also, because I've sent out a few emails lately, I've been receiving several requests from people to be "unsubscribed." Ciara says that she cannot handle this. Is there a written procedure that I can either post on the web or just send to people who want to get off the list? Thanks, Mary -- Mary X. Tang, Ph.D. National Nanofabrication Users' Network Stanford Nanofabrication Facility CIS Room 136, Mail Code 4070 Stanford, CA 94305 (650)723-9980 mtang at snf.stanford.edu From bmurray at snf.stanford.edu Tue Mar 19 00:05:48 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 19 Mar 2002 00:05:48 -0800 (PST) Subject: Status Message-ID: John and Mike, The bug struck again this afternoon at 15:05. The additional logging helped me to identify another bug which *appears* to be the culprit. I have fixed the bug, installed the fix, and restarted the servers. Now we'll have to wait for the condition which causes the problem to arise again. Although I cannot recreate the condition, I believe that I can identify the condition when I see it in the logs. So I should be able to confirm that I do or don't have it fixed. Bill From shott at snf.stanford.edu Tue Mar 19 14:00:04 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 19 Mar 2002 14:00:04 -0800 Subject: Email Lists References: <3C96455C.927159D8@snf.stanford.edu> Message-ID: <3C97B4E4.A709C020@snf.stanford.edu> Mary: In general, we don't want people manually subscribing/unsubscribing on their own to our mailing list. There are several reasons for this: 1. Some people, even though they are still active users, would unsubscribe to reduce the volume of what they perceive to be "junk" mail ... we don't want people to be albe to do this and assume that if they are qualified on a piece of equipment that they recieve and read their e-mail. 2. Usually, when people ask to be removed from all mailing lists they mean "I've left the lab ...". When I remove someone from all lists (I've got a script to do this ...) I also "deactivate" them which removes them from the list of currently active users. While this could be better automated ... and we should probably also explicilty terminate their qualification on all pieces of equipment, this is the only way that we currently avoid having an ever increasing list of "active" users. 3. We currently assume that all e-mail should be sent to member_name at snf.stanford.edu ... and that if they have mail_forwarding to some_other_name at your_company_name_here, then that is controlled by having their e-mail forwarding controlled in only one location. In particular, even if they change their e-mail forwarding location, we don't have to change any of their e-mail subscriptions because sending it to member_name at snf.stanford.edu will get it to the proper location ... assuming, of course, that they have changed their mail forwarding address. For this reason, we don't want people to be able to manually subscribe to lists because we don't want to incur the support of a bunch of non-snf e-mail addresses. So, the best procedure is to send me e-mail of who needs to be unsubscribed ... and I will both unsubscribe them and deactivate their membership. I hope this helps, John From bmurray at snf.stanford.edu Tue Mar 19 14:36:12 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 19 Mar 2002 14:36:12 -0800 (PST) Subject: Yes! Message-ID: John and Mike, >From the logs, it appears that the condition that had been hanging the admin server occurred at 13:02:00 today, and the admin server did not hang! I think we've got this one fixed (finally). Bill From shott at snf.stanford.edu Tue Mar 19 14:54:35 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 19 Mar 2002 14:54:35 -0800 Subject: Yes! References: Message-ID: <3C97C1AB.CB3CDB09@snf.stanford.edu> Bill: That is great news!!! ... is the condition that you were looking for a case where the enterLab: looking up ... and the enterLab: adding current log entries were separated by other thread activity? I'll lookforward to hearing what you have found .... Also, I notice that we are at a total of something like 6500 transactions ... this seems like a lower number than we were seeing previously, but, it appears, as if the various heartbeat frequencies haven't changed. Is my "mental calibration" scale simply off. In any event, I'm hopeful that we've got this one pinned down and fixed ... Talk to you tomorrow, John From bmurray at snf.stanford.edu Tue Mar 19 15:48:37 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 19 Mar 2002 15:48:37 -0800 (PST) Subject: Yes! In-Reply-To: <3C97C1AB.CB3CDB09@snf.stanford.edu> Message-ID: John, On Tue, 19 Mar 2002, John Shott wrote: > Bill: > > That is great news!!! ... is the condition that you were looking for a case > where the enterLab: looking up ... and the enterLab: adding current log > entries were separated by other thread activity? > That's correct. It was very similar to the first bug I fixed. It was another situation where I was synchronizing on the wrong object, in this case a PreparedStatement, for a very brief moment instead of synchronizing on the sql Connection. So it took just the right sequence of events to cause the problem. > > Also, I notice that we are at a total of something like 6500 transactions ... > this seems like a lower number than we were seeing previously, but, it > appears, as if the various heartbeat frequencies haven't changed. Is my > "mental calibration" scale simply off. > This is considerably lower. I was incorrect in assuming that the problem was related to the number of transactions. It's really most closely related to load. Basically we needed a local client to register and call enterLab while another thread had the database locked. That happened three times on Friday. Although Friday was a bad day, the logs provided me with enough information to find a bug. It's definitely a bug, and I'm pretty sure it's *the* bug. Bill From bmurray at snf.stanford.edu Thu Mar 21 10:39:00 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 21 Mar 2002 10:39:00 -0800 (PST) Subject: [GECOS] CERT Advisory CA-2002-08 Multiple vulnerabilities in Oracle Servers (fwd) Message-ID: John and Mike, I reveiwed this list quickly. I don't believe that we're using any of the features subject to these security problems. However, when we install 9i we should apply all the latest Oracle patches. Bill ---------- Forwarded message ---------- Date: Thu, 21 Mar 2002 10:24:21 -0800 (PST) From: Joe Little To: gecos at island.stanford.edu Subject: [GECOS] CERT Advisory CA-2002-08 Multiple vulnerabilities in Oracle Servers (fwd) FYI if you use oracle ---------- Forwarded message ---------- Date: Thu, 14 Mar 2002 13:49:04 -0500 (EST) From: CERT Advisory To: cert-advisory at cert.org Subject: CERT Advisory CA-2002-08 Multiple vulnerabilities in Oracle Servers -----BEGIN PGP SIGNED MESSAGE----- CERT Advisory CA-2002-08 Multiple vulnerabilities in Oracle Servers Original release date: March 14, 2002 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Systems running Oracle8i Database * Systems running Oracle9i Database * Systems running Oracle9i Application Server Overview Multiple vulnerabilities in Oracle Application Server have recently been discovered. These vulnerabilities include buffer overflows, insecure default settings, failures to enforce access controls, and failure to validate input. The impacts of these vulnerabilities include the execution of arbitrary commands or code, denial of service, and unauthorized access to sensitive information. I. Description Oracle Application Server includes a web server based on the Apache HTTP Server. Oracle extends the web server with a number of different components that can be used provide interfaces to database applications. These components include, but are not limited to, a Procedural Language/Structured Query Language (PL/SQL) module, Java Server Pages, XSQL Servlets, and Simple Object Access Protocol (SOAP) applications. The vulnerabilities referenced in this advisory were reported in several publications by David Litchfield of NGSSoftware: * Hackproofing Oracle Application Server http://www.nextgenss.com/papers/hpoas.pdf * NGSSoftware Insight Security Research Advisory #NISR20122001 http://www.nextgenss.com/advisories/plsql.txt * NGSSoftware Insight Security Research Advisory #NISR06022002A http://www.nextgenss.com/advisories/oraplsextproc.txt * NGSSOftware Insight Security Research Advisory #NISR06022002B http://www.nextgenss.com/advisories/oraplsbos.txt * NGSSoftware Insight Security Research Advisory #NISR06022002C http://www.nextgenss.com/advisories/orajsa.txt http://www.nextgenss.com/advisories/orajsp.txt For the complete list of Oracle-related vulnerabilities published by the CERT/CC, please search the Vulnerability Notes Database using the term 'Oracle'. Details about specific vulnerabilies can be found in the appropriate vulnerability note. Oracle has addressed these vulnerabilities with patches and recommended configuration changes. For more information please see the vendor information for Oracle in Appendix A. Buffer overflows Several buffer-overflow vulnerabilities exist in the way the PL/SQL module handles HTTP requests and configuration parameters. Default configuration settings in a range of components are insecure, and different components fail to apply access restrictions uniformly. These vulnerabilities expose both the systems running Oracle Application Server and the information held in the underlying databases to undue risk. Two more buffer overflow vulnerabilities exist in code that processes configuration parameters. These parameters processes configuration parameters that can be specified via the PL/SQL gateway web administration interface. By default, access to the PL/SQL gateway web administration interface is not restricted [VU#611776]. VU#500203 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via help page request VU#313280 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via HTTP Location header VU#750299 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via HTTP request VU#878603 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via HTTP Authorization header VU#659043 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via Database Access Descriptor password VU#923395 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via cache directory name Insecure default configurations The default installation of Oracle Application Server includes a number of insecure configuration settings, such as well-known default passwords and unrestricted access to applications and sensitive information. VU#307835 - Oracle9i Application Server OWA_UTIL procedures expose sensitive information VU#736923 - Oracle 9iAS SOAP components allow anonymous users to deploy applications by default VU#611776 - Oracle9i Application Server PL/SQL Gateway web administration interface uses null authentication by default VU#698467 - Oracle 9iAS default configuration allows access to "globals.jsa" file VU#476619 - Oracle 9iAS default configuration allows arbitrary users to view sensitive configuration files VU#712723 - Oracle 9iAS default configuration uses well-known default passwords VU#168795 - Oracle 9iAS allows anonymous remote users to view sensitive Apache services by default VU#278971 - Oracle 9i Application Server does not adequately handle requests for nonexistent JSP files thereby disclosing web folder path information Failure to enforce access controls Oracle Application Server does not uniformly enforce access restrictions. Different components do not adequately check authorization before granting access to protected resources. VU#180147 - Oracle 9i Database Server PL/SQL module allows remote command execution without authentication VU#193523 - Oracle 9i Application Server allows unauthenticated access to PL/SQL applications via alternate Database Access Descriptor VU#977251 - Oracle 9iAS XSQL Servlet ignores file permissions allowing arbitrary users to view sensitive configuration files VU#547459 - Oracle 9iAS creates temporary files when processing JSP requests that are world-readable Failure to validate input In one case, the PL/SQL module does not properly handle a malformed HTTP request. VU#805915 - Oracle9i Application Server Apache PL/SQL module does not properly handle HTTP Authorization header II. Impact The impacts of these vulnerabilities include the remote execution of arbitrary code, remote execution of commands and SQL queries, disclosure of sensitive information, and denial of service. Remote execution of arbitrary commands and code This section contains vulnerabilities that permit a remote intruder to cause a denial of service or execute arbitrary commands, code, or queries on the system. Some of these vulnerabilities allow execution with the privileges of the Apache process. On UNIX systems, the Apache process typically runs as the "oracle" user. On Windows systems, the Apache service typically runs as the SYSTEM user; therefore, an attacker could gain complete control of the system by exploiting these vulnerabilities. VU#500203 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via help page request VU#313280 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via help page request Location: header VU#750299 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via HTTP request VU#878603 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via HTTP Authorization header password parameter VU#659043 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via Database Access Descriptor password VU#923395 - Oracle9i Application Server Apache PL/SQL module vulnerable to buffer overflow via cache directory name VU#180147 - Oracle 9i Database Server PL/SQL module allows remote command execution without authentication VU#736923 - Oracle 9iAS SOAP components allow anonymous users to deploy applications by default VU#712723 - Oracle 9iAS default configuration uses well-known default passwords VU#611776 - Oracle9i Application Server PL/SQL Gateway web administration interface uses null authentication by default Unauthorized access to sensitive information A number of vulnerabilities disclose configuration information or expose data stored in underlying databases. Also, insecure applications could allow an intruder to execute SQL queries. Oracle system programmers may wish to examine these vulnerabilities in Oracle's sample pages to prevent similar vulnerabilities in their own Oracle applications. VU#307835 - Oracle9i Application Server OWA_UTIL PL/SQL application exposes procedures that are remotely accessible by arbitrary users VU#193523 - Oracle 9i Application Server allows unauthenticated access to PL/SQL applications via alternate Database Access Descriptor VU#698467 - Oracle 9iAS default configuration allows access to "globals.jsa" file VU#476619 - Oracle 9iAS default configuration allows arbitrary users to view sensitive configuration files VU#977251 - Oracle 9iAS XSQL Servlet ignores file permissions allowing arbitrary users to view sensitive configuration files VU#168795 - Oracle 9iAS allows anonymous remote users to view sensitive Apache services by default VU#278971 - Oracle 9i Application Server does not adequately handle requests for nonexistent JSP files thereby disclosing web folder path information VU#547459 - Oracle 9iAS creates temporary files when processing JSP requests that are world-readable Denial of service In the case where the PL/SQL module does not properly handle an HTTP request, a denial-of-service vulnerability exists. Also, an unsuccessful attempt to exploit a buffer overflow vulnerability could crash the Apache service. VU#805915 - Oracle9i Application Server Apache PL/SQL module does not properly handle HTTP Authorization header III. Solution Oracle has provided patches and workarounds that address most of these vulnerabilities. Sites using Oracle Application Server are encouraged to install the appropriate patches and make the recommended configuration changes provided by Oracle. Solutions and workarounds for specific vulnerabilities can be found in individual vulnerability notes and in the following Oracle security alerts: * Oracle Security Alert #29 http://otn.oracle.com/deploy/security/pdf/plsextproc_alert.pdf * Oracle Security Alert #28 http://otn.oracle.com/deploy/security/pdf/ias_modplsql_alert.pdf * Oracle Security Alert #25 http://otn.oracle.com/deploy/security/pdf/modplsql.pdf * Oracle Security Alert #22 http://otn.oracle.com/deploy/security/pdf/ias_soap_alert.pdf Security and patch information for Oracle products are available at the following locations: * Oracle Security Alerts http://otn.oracle.com/deploy/security/alerts.htm * MetaLink (registration required) http://metalink.oracle.com/ Sites using Oracle Application Server may also find David Litchfield's Hackproofing Oracle Application Server paper useful in describing the impacts and various interactions of these vulnerabilities. Apply a patch Oracle has released patches that address some of these vulnerabilities. Patch information can be found in Oracle Security Alert #28 and Oracle Security Alert #25 and on the MetaLink web site (registration required). Secure default configuration Oracle has provided documentation on changing vulnerable default configuration settings. For details, consult individual Vulnerability Notes and the Oracle Security Alerts referenced in Appendix A. _________________________________________________________________ The CERT Coordination Center thanks David Litchfield and Oracle for information used in this document. _________________________________________________________________ Authors: Art Manion, Jason Rafail, and Shawn Van Ittersum _________________________________________________________________ Appendix A. - Vendor Information This appendix contains statements provided by vendors for this advisory. We will update this section as vendors provide new or modified statements, and we will note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Appendix B. - References 1. http://www.kb.cert.org/vuls/id/500203 2. http://www.kb.cert.org/vuls/id/313280 3. http://www.kb.cert.org/vuls/id/750299 4. http://www.kb.cert.org/vuls/id/878603 5. http://www.kb.cert.org/vuls/id/659043 6. http://www.kb.cert.org/vuls/id/923395 7. http://www.kb.cert.org/vuls/id/307835 8. http://www.kb.cert.org/vuls/id/736923 9. http://www.kb.cert.org/vuls/id/611776 10. http://www.kb.cert.org/vuls/id/698467 11. http://www.kb.cert.org/vuls/id/476619 12. http://www.kb.cert.org/vuls/id/712723 13. http://www.kb.cert.org/vuls/id/168795 14. http://www.kb.cert.org/vuls/id/278971 15. http://www.kb.cert.org/vuls/id/180147 16. http://www.kb.cert.org/vuls/id/193523 17. http://www.kb.cert.org/vuls/id/977251 18. http://www.kb.cert.org/vuls/id/805915 19. http://www.kb.cert.org/vuls/id/547459 20. http://www.nextgenss.com/papers/hpoas.pdf 21. http://www.nextgenss.com/advisories/plsql.txt 22. http://www.nextgenss.com/advisories/oraplsextproc.txt 23. http://www.nextgenss.com/advisories/oraplsbos.txt 24. http://www.nextgenss.com/advisories/orajsa.txt 25. http://www.nextgenss.com/advisories/orajsp.txt 26. http://otn.oracle.com/deploy/security/pdf/plsextproc_alert.pdf 27. http://otn.oracle.com/deploy/security/pdf/ias_modplsql_alert.pdf 28. http://otn.oracle.com/deploy/security/pdf/modplsql.pdf 29. http://otn.oracle.com/deploy/security/pdf/ias_soap_alert.pdf ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-2002-08.html ______________________________________________________________________ CERT/CC Contact Information Email: cert at cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo at cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 2002 Carnegie Mellon University. Revision History March 14, 2002: Initial release -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQCVAwUBPJDsH6CVPMXQI2HJAQHgiwP+JCqCffr8d7JQejHAqJFiZGs8bnOsz4+k Fw22F6K3xaZLptM8yHo8a1KDZPEgZ9q4PkCs+VzjHxZp+xkt3eASgGctZ75xUrh0 Tt5UhitcS0R6vuH3/jKJmMqaNyszxmdcndm49SxgzUNM4JnI+h4GfjO3pTGxKyqr Ly39M389sLE= =qEP3 -----END PGP SIGNATURE----- _______________________________________________ GECOS mailing list GECOS at island.stanford.edu http://island.stanford.edu/mailman/listinfo/gecos From bmurray at snf.stanford.edu Thu Mar 21 10:48:39 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 21 Mar 2002 10:48:39 -0800 (PST) Subject: Status Message-ID: John and Mike, The Coral servers have been up and running without problems for 3 1/2 days. The admin server has handled 32,500 transactions with no problems. So I think we've probably got that bug fixed. Unfortunately, I didn't make much progress on Mahnaz's new machine. So I'll try to get to that on Friday. I'm now focusing my efforts on the few remaining problems running Coral on the PostgreSQL/Linux platform. Since JavaOne begins next week, I'd really like to get these items resolved this week. Then upon our return in April, we can get Oracle and Coral installed on the new hardware which Mike has ready to go. Bill PS John, no word from Penn State yet? From shott at snf.stanford.edu Thu Mar 21 10:57:18 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 21 Mar 2002 10:57:18 -0800 Subject: Status References: Message-ID: <3C9A2D0E.FC6F189A@snf.stanford.edu> Bill" No, nothing from them. I'm beginning to worry ... I have to be in Washington on May 6 at NSF and ABSOLUTELY don't want to have to tell them that Coral isn't running at Penn State (even if it is Penn State's fault ....). I'll try to send them a kick-start e-mail later today. Thanks, John From bmurray at snf.stanford.edu Thu Mar 21 13:21:57 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 21 Mar 2002 13:21:57 -0800 (PST) Subject: Sun Forte Message-ID: John and Mike, Based on Ike's comment below, maybe we should consider Sun Forte. Bill On the standard development subject: I'm open to all environments. I have been using Sun Forte for Java 3.0 Community Edition. It's free and it supports Linux, Solaris, and Windows platform. It takes care of the tab/space problem by simply setting the editor options. It also supports CVS although I've never tried it. Ike From cpreston at snf.stanford.edu Thu Mar 21 15:49:41 2002 From: cpreston at snf.stanford.edu (ciara preston) Date: Thu, 21 Mar 2002 15:49:41 -0800 Subject: Coral account Message-ID: <3C9A7195.CE4E7ABE@snf.stanford.edu> Your Coral Password: S96Yxl Capital S, numbers 9, 6, capital Y, small x, l -- Ciara Preston Lab Services Administrator Stanford Nanofabrication Facility Phone 650-725-3664 From shott at snf.stanford.edu Fri Mar 22 19:51:03 2002 From: shott at snf.stanford.edu (John Shott) Date: Fri, 22 Mar 2002 19:51:03 -0800 Subject: [Fwd: development environment] Message-ID: <3C9BFBA7.83C0CE19@snf.stanford.edu> Bill and Mike: Here is a response from Ike related to Sun Forte vs. IBM Visual Age for Java ... the biggest concern I see, particularly for VA, is that they are well behind on the JDK that they support and I'm pretty certain that we are locked in to 1.4 for other (important) reasons. However, hopefully Sun will be getting Forte support for 1.4 out of beta quickly ... Thanks, John -------------- next part -------------- An embedded message was scrubbed... From: Ike Lin Subject: Re: development environment Date: Fri, 22 Mar 2002 09:55:24 -0500 Size: 2395 URL: From bmurray at snf.stanford.edu Sat Mar 23 10:16:25 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 23 Mar 2002 10:16:25 -0800 (PST) Subject: Tagged Version Message-ID: John, Should I tag the version we installed last night on rosen or do you have additional changes you want to make to the makefiles? Thanks, Bill From shott at snf.stanford.edu Sat Mar 23 16:47:44 2002 From: shott at snf.stanford.edu (John Shott) Date: Sat, 23 Mar 2002 16:47:44 -0800 Subject: Rsync problems ... Message-ID: <3C9D2230.DBE97650@snf.stanford.edu> Bill and Mike: I think that I know why we are having problems with rysnc on guilden and believe that it is related to not having things set up there properly. It complains about not finding a run-time library (libpopt.so.0, I think). I had previously installed some utilities that, I think, included this library. Initially, I thought that the problem was with the environment variable LD_LIBRARY_PATH ... while I sort of know that this gave the search sequence for various libraries, etc, I'd never really felt confident of how to set it. However, it turns out .... you guys may have already known this ... that the use of LD_LIBRARY_PATH is frowned upon (although still supported) in Solaris 8. Why? As near as I can tell, because Solaris 8 seems to support for 32- and 64-bit applications as well as secure applications which, apparently, need different libraries, etc. So the use of LD_LIBRARY_PATH variable has been replace with something called "crle" ... which stands for "configure runtime linking environment" and would have a file called /var/ld/ld.config as the default for 32-bit applications and /var/ld/64/ld.config for 64-bit applications. It appears as if these don't exist on guilden ... you'd think that it would be set up with some default initial configuration, but that doesn't appear to be the case. So, I'm pretty certain that our rysnc problems have nothing to do with different versions of rsync on different machine ... and more to do with not having guilden set up to look in the proper places. Mike, I'm wondering whether this is related to the gcc problems that you are seeing on atu? Now, while I think I know the problem, I have yet to find the "crle for dummies" article that tells me how to set this up for most things ... the man page gives some clues, but I'd feel better if I could find something that is a little more comprehensive. I'll try to find more a more expert source of information as to how to do this ... but if you folks have a pointer to this, I'm all ears. Thanks, have fun at Java One ... John From shott at snf.stanford.edu Tue Mar 26 19:01:50 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 26 Mar 2002 19:01:50 -0800 Subject: Linux/Postgres update ... Message-ID: <3CA1361E.9D1F9182@snf.stanford.edu> Bill and Mike: I hope that things are going well at Java One. I've made a bit of progress here: 1. rsync now works to/from guilden ... crle problem on guilden. 2. Guilden servers can now connect to the postgres database on spf ... it turns out that spf still had a 192.168.0.103 entry on guilden:/etc/hosts (instead of 104). 3. Minor cleanup of makefile stuff. The resource client exception that results in the "Unmarshaller" problem when we try to fire up the resource client is definitely more related to the database than to the server ... even though it is the client that seems to notice the problem. Here is what I find ... 1. Client running on bopeep against servers on guilden against the postgres database on spf ... resource client fails. 2. Change the database from Postgres (on spf) to Oracle (on bopeep) and everything is fine. 3. Client running on shott against servers on spf against ther oracle database on bopeep .... everything is fine. 4. Change the database from Oracle (on bopeep) to Postgres (on spf) and the resource client fails. What is surprising, however, is the fact that the resource manager seems to think that it read all of the member/projects/accounts from either Postgres or Oracle ... but the client seems to develop a problem if that data came from the Postgres database. I'm sort of wondering whether the server is getting some sort of twisted information when it does it's getAllMembers call ... but not twisted enough to cause it to complain ... but that when it tries to pass it on to the client that everything is OK. Wierd ... Oh well, talk to you soon, John From bmurray at snf.stanford.edu Wed Mar 27 10:06:35 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 27 Mar 2002 10:06:35 -0800 (PST) Subject: Linux/Postgres update ... In-Reply-To: <3CA1361E.9D1F9182@snf.stanford.edu> Message-ID: John, That's interesting. I think we'll need to put some debugging output in the servers on spf to track this down. JavaOne is great, but the days are long. Also, I can't get access to my mail from the conference. No ssh. Talk to you soon, Bill On Tue, 26 Mar 2002, John Shott wrote: > Bill and Mike: > > I hope that things are going well at Java One. > > I've made a bit of progress here: > > 1. rsync now works to/from guilden ... crle problem on guilden. > 2. Guilden servers can now connect to the postgres database on spf ... it > turns out > that spf still had a 192.168.0.103 entry on guilden:/etc/hosts (instead of > 104). > 3. Minor cleanup of makefile stuff. > > The resource client exception that results in the "Unmarshaller" problem when > we try to fire up the resource client is definitely more related to the > database than to the server ... even though it is the client that seems to > notice the problem. > > Here is what I find ... > 1. Client running on bopeep against servers on guilden against the postgres > database on spf ... resource client fails. > > 2. Change the database from Postgres (on spf) to Oracle (on bopeep) and > everything is fine. > > 3. Client running on shott against servers on spf against ther oracle database > on bopeep .... everything is fine. > > 4. Change the database from Oracle (on bopeep) to Postgres (on spf) and the > resource client fails. > > What is surprising, however, is the fact that the resource manager seems to > think that it read all of the member/projects/accounts from either Postgres or > Oracle ... but the client seems to develop a problem if that data came from > the Postgres database. > > I'm sort of wondering whether the server is getting some sort of twisted > information when it does it's getAllMembers call ... but not twisted enough to > cause it to complain ... but that when it tries to pass it on to the client > that everything is OK. > > > Wierd ... > > Oh well, talk to you soon, > > John > From shott at snf.stanford.edu Thu Mar 28 17:37:01 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 28 Mar 2002 17:37:01 -0800 Subject: Resource client working ... elimination of funny codes. Message-ID: <3CA3C53D.50D4B0CA@snf.stanford.edu> Bill and Mike: I am pleased to report that the resource client now appears to be working when talking to a Postgres database. The "funny character" that seemed to be causing the problem is an ASCII character 141 (decimal), \215 octal, or 8D Hex. It appears as if the Oracle to Postgres conversion faithfully read and reloaded this character. Why it seems to be the Corba communication that dies only when talking to the Postgres database and not apparently, when receiving the same character from an Oracle database ... I have no idea. In any event, elimination of firstname = R\215 for member with name = cnri0452 and cnri0477 and elination of members with name kle\215 and standard\215\215\215 and elimnation of their entries in works_on ... caused things to spring to life. Bill, I think that this may be a "Mary Donoghue strikes again" situation because all of these entries date from her tenure. I've got a vague recollection that we encountered this problem in the past ... and that the "trim" that is now doen in the resource client (as opposed to the old "add" client) may have fixed that problem. Just so that nobody has to look it up ... the oracle and postgres statements that find these abnormal firstnames are: Oracle: select name from member where firstname = concat('R',chr(141)); Postgres: select name from member where firstname = 'R\215'; Tomorrow morning (Friday), I'm going to try to do a nice, clean install of both the -dev server (Server = guilden, database = oracle on bopeep) and the -linux server (Server = spf, database = postgres on spf). At that point, we should be able to tag what we have and be reasonably certain that it is a big improvement over the last tagged version. Thanks ... enjoy the final bit of Java One. John p.s. This morning we appeared to experience about a 10 minute Coral outage ... a second copy of the Admin Server apparently tried to start which, I think, killed the first one which then caused all of the clients to need to restart. While I can't be certain ... I don't think that I accidentally started a second set of servers and it wasn't a time that I was playing with servers on other machines ... although I'm sure that I'm the prime suspect and can't rule out that did something stupid.