From shott at snf.stanford.edu Tue Jan 1 09:46:36 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 01 Jan 2002 09:46:36 -0800 Subject: Guilden restore ... Message-ID: <3C31F5FC.5A358A3E@snf.stanford.edu> Bill and Mike: Note: I know that you will unlikely be able to read this until guilden is back on the air, but I'm hopeful I will somehow be able to print this to leave you a hard copy ... I see that you have done a restore onto guilden ... there was a huge list of errors generated in a file name BEX02.txt. I've taken the liberty of copying this file to sunray:/tmp/BEX02.txt. I've also generated a somewhat shortenend version of this file that only contains the directories that it cannot access and stored that as sunray:/tmp/BEX02-denied.txt. (This was generated with: "grep / BEX02.txt > BEX02-denied.txt") It appears as if it could not restore any of the /app or the /home/Devel or /home/Student stuff. My first guess would be that these are what is on the external SCSI drives and that this is probably OK. One thing that I am, however, a bit worried about: It isn't clear that the disk that we replaced was partitioned in the same way as the one that failed ... if that partitioning wasn't the same, I'm worried that there will be some sort of inconsistencies generated. I'm not sure, however, that I know how to determine what the partitioning of the disk currently is and how we can compare that to what it used to be. But, hopefully we will be close to resuming full operations ... Good luck, John From shott at snf.stanford.edu Wed Jan 2 17:13:25 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 02 Jan 2002 17:13:25 -0800 Subject: New hardware and disk partitioning ... Message-ID: <3C33B035.DF96D8FA@snf.stanford.edu> Bill and Mike: So that we know what we are dealing with and can plan partitioning appropriately, I think that we need to know (and compare) the memory and number/size of disks that we have on the SunBlades, the 220Rs, and on Sunray ... plus, the A100. Here is what I think we have: Sunray: Main memory: 2GB Disks: 3 x 9.1 GB 220R Servers: Main memory: 2GB Disks: 2 x 36 GB Raid: Disks: I'm not sure (plus, do we end up with a copy of everything so that physical storage is actually half of total storage? SunBlades: Main memory: 512 MB Disks: 1 x 20 GB Does this sound correct? Note: I've found a reasonably good article about Solaris System Configuration (including more details about partitioning that most people include) at a Rugters University site: http://info.rutgers.edu/Techdir/solarisbody.html After a bit more reading of this, I may try to make an initial guess at reasonable partitioning of the SunBlades and the 220Rs ... my initial impression is that we will need one "flavor" of partitioning for the one-disk Sunblades and another for the two-disk 220Rs. (And then we can later decide whether anything needs to change once we upgrade the 3500 to Solaris8 or whether we are happy with that partitioning. Thanks, John From shott at snf.stanford.edu Thu Jan 3 09:36:49 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 03 Jan 2002 09:36:49 -0800 Subject: Xtradyne Domain Boundary Controller Message-ID: <3C3496B1.CCA83D69@snf.stanford.edu> Bill and Mike: I've left each of you with a packet of stuff from Xtradnye about their Domain Boundary Controller that appears as if it would allow us to put Rosen (or whatever the new server/database machine will be called) back behind a firewall and allow our CORBA traffic to penetrate the firewall. If I am reading this stuff correctly, it would meet our needs without requiring any client/server changes ... It isn't cheap: the university discount price is $3k. But, we can afford that ... and there is no indication that other schools have anything behind firewalls so I don't think that we need to worry about what others can/cannot afford. I'm not proposing that we do anything now ... I think that our 3 highest priorities still are: 1. Getting PSU and MIT afloat. 2. Getting the new hardware configured and installed. 3. Working on the inventory manager. However, at that point, we may want to re-visit our firewall ... snf is pretty slow/old. It would cost us very little to get one (or two) new firewall machines and put RedHat7.1 on them. I think that the newer RedHat firewall stuff is a lot more friendly than the old ipfwadm stuff .... or we could even get a "real" firewall. At that point, we might want to look at the Xtradyne stuff and see if the effort/cost is worth the benefit or allowing us to put our servers and database behind the firewall once again. So, for your reading enjoyment ... or you can check out www.xtradyne.com. Thanks, John From bmurray at snf.stanford.edu Thu Jan 3 10:03:02 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 3 Jan 2002 10:03:02 -0800 (PST) Subject: Xtradyne Domain Boundary Controller In-Reply-To: <3C3496B1.CCA83D69@snf.stanford.edu> Message-ID: John and Mike, Miranda is sick again. I can't leave her with her grandmother as planned cause grandma has the flu also. It looks like I'm stuck at home today. Although I can work from home, I'm not sure that there's much at the top of the list that I can do from home today. I'm reading the Solaris packet from Rutgers at the moment. It looks like I'm going to have to take a sick day today. If there are some things I can do, let me know. I had just begun to look at the Postgres stuff when guilden died last week. Is there anything I can do there? Thanks, Bill On Thu, 3 Jan 2002, John Shott wrote: > Bill and Mike: > > I've left each of you with a packet of stuff from Xtradnye about their Domain > Boundary Controller that appears as if it would allow us to put Rosen (or > whatever the new server/database machine will be called) back behind a > firewall and allow our CORBA traffic to penetrate the firewall. > > If I am reading this stuff correctly, it would meet our needs without > requiring any client/server changes ... It isn't cheap: the university > discount price is $3k. But, we can afford that ... and there is no indication > that other schools have anything behind firewalls so I don't think that we > need to worry about what others can/cannot afford. > > I'm not proposing that we do anything now ... I think that our 3 highest > priorities still are: > > 1. Getting PSU and MIT afloat. > 2. Getting the new hardware configured and installed. > 3. Working on the inventory manager. > > However, at that point, we may want to re-visit our firewall ... snf is pretty > slow/old. It would cost us very little to get one (or two) new firewall > machines and put RedHat7.1 on them. I think that the newer RedHat firewall > stuff is a lot more friendly than the old ipfwadm stuff .... or we could even > get a "real" firewall. At that point, we might want to look at the Xtradyne > stuff and see if the effort/cost is worth the benefit or allowing us to put > our servers and database behind the firewall once again. > > So, for your reading enjoyment ... or you can check out www.xtradyne.com. > > Thanks, > > John > From shott at snf.stanford.edu Thu Jan 3 10:52:18 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 03 Jan 2002 10:52:18 -0800 Subject: Sun service contracts ... Message-ID: <3C34A862.EC7DCCC@snf.stanford.edu> Bill and Mike: I just received a phone call from Rekha Gupta (rehka.gupta at sun.com) who was calling about renewal of our service contract on our Ultra 2 ... I'm not sure whether we have guilden under service contract, so I suspect that this is rosen that she is talking about. I told here that we were on the verge of phasing out that machine and would likely let that contract lapse. However, we should review where we stand regarding our new hardware. We do have an existing contract for maintenance of the 3500 ... and they are willing to consolidate things so that we can have all machines under one contract to simplify paperwork. Am I correct in thinking that we probably want to add both 220A plus the A-1000 to our service contract. Did our original purchase include any service agreement for that hardware. Do we want to add the Sunblades in? Anything that we want to add will require the model number and serial number. Mike, would you mind getting those numbers? Do either of you recall whether we get any sort of "deal" on our service contract? In other words, should we run this through Jon Arikata? Or, alternatively, we could ask Rekha Gupta if we get any sort of a deal. Thoughts, suggestions ... Thanks, John From shott at snf.stanford.edu Thu Jan 3 13:14:00 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 03 Jan 2002 13:14:00 -0800 Subject: Synchronizing password files, setting initial password files, etc. Message-ID: <3C34C998.3E24FEE9@snf.stanford.edu> Bill and Mike: As you know, we currently use a couple of scripts to create new user accounts on sunray and snf, to set an initial password on each, set up mailforwarding, etc. It appears that we are very close to having to add a third machine (sunstar, I think) to that process. It occurs to me that this is a reaonable time to consider how we are currently doing this and see if there is a better way .... I think that there are several weaknesses with our current approach (which are my fault because I wrote the existing scripts): 1. We basically use "useradd" with the "-m" option (to make the home directory) on sunray and then use "rsh snf useradd ..." on snf without the -m since the home directory currently exists on sunray. (Actually, we also invoke these commands with sudo so that Ciara can run these commands that normally only root can run ...). This is, at best, a little awkward and most other sites are unlikely to want to create accounts on more than one machine so our existing script isn't terribly generic. Blindly adding sunstar seems a little brute force-ish ... 2. Our real achilles heel is in passwords: I have written a script called setpasswd that is a real kludge: It uses the fact that the linux version (but no the Solaris version) of passwd allows a "random" password to be set and we currently define that to consist of 2 numbers, 2 lowercase characters, and 2 uppercase characters. These are terribly unfriendly things like 0wL5sX ... and it is hard to tell whether that starts with an "0" (zero) or an "O" (uppercase O) unless you know that it is 2 numbers, 2 lowercase letters, and 2 uppercase characters. Plus, that is "on the wire" as it is returned from snf to Ciara's SunRay (usually) in clear text (well, unless sunray traffic is encoded. Then, my klugdey script asks her to type that in twice (nominally so that we confirm that she read it properly ... but what it is actually doing is running passwd (via sudo) on sunray to set the sunray password as the same as the random password that was set on snf. These are deep, dark confessions ... I'm embarrassed as I write this ... Of course, the other problem that we have is that we don't have a script that allows people to change their password on both machines .... so they have to login to snf, change it there, then login to sunray and change it there ... hopefully (but not required) to the same password. All I can say is "Yucccck!!!!". Plus, adding a third machine to this lame approach is unthinkable ... Based on the number of times that either Ciara or the user have a problem with the random password approach .... and the fact that it is written down on paper and given to them (and probably kept written down because nobody can remember one of these things and comparitively few people come to me to ask me to help change their password), I conclude that initially setting random passwords is a bad idea. I think that we would be better of if we didn't initially set a password at all and they had to go to Ciara to initially set and select their password. So, how do I think that things could be improved? NIS or NIS Plus ... no, I don't think that is the proper approach. I think that I should modify my newuser script so that it only sets up the user account on the "main machine" ... sunray, I guess ... that actually sets up the home directory. Also, I propose that we don't try to initially set up a password. Then, we rely on rsync (which can use ssh) to copy /etc/passwd and /etc/shadow ... and anything else that we need from sunray to sunstar and to snf. To set up an initial password, people would go to Ciara and she could run the "normal" passwd command (or maybe a simple script wrapped around passwd) to let them set the password that they want. I think that the rsync copy could be run at the same time that we create the new user account, and then also run it as a cron job every 10 or 15 minutes so that people's passwords would be synchronized every few minutes. Alternatively, we could probably set it up so that any invocation of newusr or passwd triggered "rsync" to update the other machines. In general, I think that this is a more sound approach and gets around some of the problems we currently have. One problem that I can envision is that, as soon as we have failover, we can't guarantee that Ciara (or anyone else) will be on sunray rather than snnstar. In particular, that makes it difficult, I think, to guarantee that sunray has the master copy of /etc/passwd and /etc/shadow. In that is the case, it is probably true that any scripts that invoke "adduser" or "passwd" need to be smart enough to know which machine they are running from and copy things to the others. In other words, if a user is added from sunstar, the script needs to know that and be smart enough to know that and know that it has to copy files to sunray and snf. Although it isn't terribly likely, I don't know what would happen if Ciara was adding a new user account on sunstar and someone else was changing their password on sunray ... So, my thinking is that this would be a better way to deal with creating accounts and passwords on multiple machines .... we create an account/password on a single machine and then, if multiple machines are involved, use rsync/ssh to copy them to other machines. I think that this increases the likelihood that the scripts that we end up would be more generic at multiple sites and also eliminates, I hope, some of the problems that we currently see as a result of trying to set an initial password. Comments, suggestions, thoughts? Thanks, John From shott at snf.stanford.edu Fri Jan 4 18:07:32 2002 From: shott at snf.stanford.edu (John Shott) Date: Fri, 04 Jan 2002 18:07:32 -0800 Subject: Minor Bug with Adjustment? Message-ID: <3C365FE4.E5ED6FD1@snf.stanford.edu> Bill: I think that I may have stumbled across a minor bug in the adjustment stuff. Here is what happened, I think: I had a couple of accounts last month that I thought that I had adjusted then: Changing 2DYA731 to 2DYA736 and 2WMN524 to 2WMD390 (I think my original adjustment was done on 12/5/01 effective date 11/01/01 ... but also included adjustments for activities in early december (12/3 and 12/4) as it should. I was a little surpirsed that when I did the december accounting, that I was getting warnings for the old accounts 2DYA731 and 2WMN524 ... but I didn't worry about it too much as I thought I must have forgotten. So, I adjusted them again ... this may not be a bug so much as it is pilot error. But it appears as if serveral of those entries have two identical adjustments .... well, except for adjustment date ... which, I think doubles their apparent usage. However, the thing that really surprised me was when I went to upload, I still had charges for 2DYA731 and 2WMN524 .... the two accounts that I had actually replaced twice. Interestingly, the equipment that these folks were using was metalica ... one of the pieces of equipment that has a setup charge but a per-minute rate of 0. I've got a suspicion that there may be a bit of a problem with the tally stuff as it applies to machines with a setup charge. Of course it doesn't help that I double-adjusted .... but, I think, my second adjustment (a month later) was based on the fact that I appeared to generate charges for an account that (I thought) I had already replaced. To be honest, this is sufficiently convoluted and it is sufficiently late in the day that I am probably not thinking accurately .... but I think that there may be something amiss. I've got a couple of Excel files that, hopefully, will shed some light on things ... I think I've got the pertinent parts of the ajustment table as well as the appropriate entries in the activity table. Have a good weekend, John From mahnaz at snf.stanford.edu Tue Jan 8 08:52:16 2002 From: mahnaz at snf.stanford.edu (Mahnaz Mansourpour) Date: Tue, 08 Jan 2002 08:52:16 -0800 Subject: Adding and deleting Message-ID: <3C3B23BF.8B352827@snf.stanford.edu> Hello.... we need to add the new track to the system. We can call it Svgcoat2. we need to add the YES prime oven as well but I am not sure if we will be able to control it via enabling and disabling. We need to take the OAI out. mahnaz From shott at snf.stanford.edu Tue Jan 8 11:55:38 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 08 Jan 2002 11:55:38 -0800 Subject: Did Coral hang/die monday night? Message-ID: <3C3B4EBA.68FD514F@snf.stanford.edu> Bill and Mike: I got a phone message sometime last night indicating that Coral had died ... I'm not sure what time this was and I haven't taken the time to look in the log files, but Chris Storment appeared to think that the person using the elliposometer was unable to disable it at about 9:30 p.m. ... at which point Chris storment began to use it but also thought that he was unable to disable it at about 12:30 p.m. I'm going to go in and correct/cleanup their eq_activity records. Thanks, John From bmurray at snf.stanford.edu Tue Jan 8 12:41:20 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 8 Jan 2002 12:41:20 -0800 (PST) Subject: Bug? Message-ID: John, The Coral problem that Storment reported does sound like the problem we were having earlier where no one can continue because the first call to register or heartbeat does not return. This could be my bug, but I'm not sure it is. Here's my reasoning. First, I've carefully checked all this code to make sure that everything is synchronized so that deadlocks can't occur. Second, even if a deadlock occurred in the server-side code, the ORB should time out and eventually throw a CORBA exception back to the client which we would see in the logs. Sun made a lot of changes (improvements) to the CORBA code in JDK 1.4. Perhaps, they introduced a bug? Some of our users appear to be starting a number of clients in quick succession. This would result in a number of almost simultaneous calls to register and heartbeat which could push the ORB to fail, if it were going to. Any ideas? Bill From shott at snf.stanford.edu Tue Jan 8 13:07:54 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 08 Jan 2002 13:07:54 -0800 Subject: Solaris security patch ... Message-ID: <3C3B5FAA.2D072BC@snf.stanford.edu> Bill and Mike: In the process of downloading some software, I find that there is a solaris patch that fixes a "buffer overflow" problem that allows unsavory people to get root access to Solaris machines. I've downloaded and installed the 2.6 version on sunray, rosen, and bopeep. I've also downloaded and installed it on guilden ... but not on the other SunBlade on on either of the 220Rs. The patch lives in the directory /app/solaris/8.0/patches and is numbered 111085-02. On Solaris8, this patch would be applied (assuming that sunray:/app is mounted on those machines ... which they probably aren't yet ...) patchadd /app/solaris/8.0/patches/111085-02 or, if you have already done a "cd /app/solaris/8.0/patches", then you can say: patchadd ./111085-02 Note: at the moment on guilden, you actually have to say /usr/sbin/patchadd ... we should modify the startup stuff so that root's enviroment includes /usr/sbin in it's path. Oh yes, one other thing to be adjusted: bopeep can't seem to mount the /home/Devel stuff from guilden ... it claims to have a "Stale NFS file handle". Thanks, John From shott at snf.stanford.edu Tue Jan 8 13:40:02 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 08 Jan 2002 13:40:02 -0800 Subject: Bug? References: Message-ID: <3C3B6732.F23B7F66@snf.stanford.edu> Bill: No, I don't have a great idea. However, I think that we should look at modifying the client logging in some fashion so that we can, hopefully, get an indication of a client that didn't start properly ... or some logging that gives an indication of a normally operating client so taht we can better identify a log file that represents a "wedged client" from one that successfully started, but doesn't show any other abnormal logging. Would we get a useful log entry if we added something like: System.out.println("Client starting normally!"); after the two lines at the end of the main method in Labnet.java: Labnet labnet = new Labnet(args[0]); labnet.setVisible(true); I think that what you are saying is the the HeartBeat method called during all of the initialization stuff never returns ... so, if my thinking is correct, we would only print the "Client starting normally!" message once the client becomes visible ... which is dependent on the fact that the HeartBeat returned normally. Or am I oversimplifiying? Thanks, John From shott at snf.stanford.edu Tue Jan 8 13:51:12 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 08 Jan 2002 13:51:12 -0800 Subject: Patches required for Java 1.4 beta 3 on guilden ... Message-ID: <3C3B69D0.EBA7B3AA@snf.stanford.edu> Bill: It appears as if we need 7 or 8 patches on guilden before we can load/run j2se there .... I will begin to try to download and install those patches. Are you on guilen this afternoon? ... in case I need to reboot to make those patches take effect? Thanks, John From bmurray at snf.stanford.edu Tue Jan 8 13:58:20 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 8 Jan 2002 13:58:20 -0800 (PST) Subject: Patches required for Java 1.4 beta 3 on guilden ... In-Reply-To: <3C3B69D0.EBA7B3AA@snf.stanford.edu> Message-ID: John, Yes, on and off, but you can reboot whenever you need to. Bill On Tue, 8 Jan 2002, John Shott wrote: > Bill: > > It appears as if we need 7 or 8 patches on guilden before we can load/run j2se > there .... > > I will begin to try to download and install those patches. Are you on guilen > this afternoon? ... in case I need to reboot to make those patches take > effect? > > Thanks, > > John > From shott at snf.stanford.edu Tue Jan 8 15:06:11 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 08 Jan 2002 15:06:11 -0800 Subject: Restarted servers .... Message-ID: <3C3B7B63.9373AFBC@snf.stanford.edu> Bill: Apparently new Coral clients were not showing ... starting at something like 2:30 or 2:45 this afternoon. I restarted the servers at about 2:45 p.m. Thanks, John From bmurray at snf.stanford.edu Tue Jan 8 15:24:16 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 8 Jan 2002 15:24:16 -0800 (PST) Subject: Restarted servers .... In-Reply-To: <3C3B7B63.9373AFBC@snf.stanford.edu> Message-ID: John, I'll add some logging now including the message you suggested. Bill On Tue, 8 Jan 2002, John Shott wrote: > Bill: > > Apparently new Coral clients were not showing ... starting at something like > 2:30 or 2:45 this afternoon. I restarted the servers at about 2:45 p.m. > > Thanks, > > John > From bmurray at snf.stanford.edu Tue Jan 8 23:38:54 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 8 Jan 2002 23:38:54 -0800 (PST) Subject: Lots of Logging Message-ID: John, I have installed new versions of the servers, local client, and remote client for Coral with extensive logging. I'm a little worried about the size the admin manager log may grow to. Until the error occurs again, I believe we need the detailed logging that I've added. Since you and Mike will arrive before I do tomorrow, could check the size of the logs on rosen in /var/log/labnet. If we're running out of space, perhaps you could compress the admmgr.log and save it elsewhere. Thanks, Bill From shott at snf.stanford.edu Wed Jan 9 08:46:04 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 09 Jan 2002 08:46:04 -0800 Subject: Lots of Logging References: Message-ID: <3C3C73CC.4101F7A3@snf.stanford.edu> Bill: Ok, so far the logging isn't too enormous. Note: at about 7:45 to 7:50 this morning, I had to restart the utsession stuff ... there were a bunch of green_newts that I couldn't kill automatically so I did a /etc/init.d/utsvc restart. This resulted in a series of "Found a dead local client ..." messages in admmgr.log at about that time. Also, on reflection, I think that some of the core files and the hs_err_pid JVM errors may be Netscape crashes ... not coral client crashes. We've heard for some time about the folks for whom netscape crashes when they try to get to things like yahoo mail that is, I think, crashing when their application is trying to load java. When I have installed J2SE, I have also installed the Netscape java plugin for 1.4beta 3 .... this may have been a mistake (or done incorrectly). I think that I've removed that (as of this morning) so we'll see whether any of the hs_err_pid and core files begin to go away. Talk to you later, John From shott at snf.stanford.edu Wed Jan 9 16:01:23 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 09 Jan 2002 16:01:23 -0800 Subject: Disk partitions for 220Rs ... Message-ID: <3C3CD9D3.72518136@snf.stanford.edu> Bill and Mike: In terms of partitioning the 220Rs, we have 2 36 GB drives on them ... At the moment, they each appear to have the first 36 GB drive set up with 6 GB for /tmp (AKA /var/run) and the remaining 30 GB as /. While most people seem to say that 2 X main memory is all one needs for swap, I don't think that it is worth the trouble to reduce that from 6 GB to 4 GB. For the second drive on each machine (I don't know if they are partitioned at all, yet, but they don't appear to be mounted), my proposal for them would be: 6 GB swap ... it seems as if most folks recommend having a swap on each disk. 15 GB for /opt (including /opt/local which will get linked to /usr/local) As the Guy from Rutgers points out, this would allow us to preserve all of our optional and third party sofware if we lost the root partition and had to reload the system. It also should improve performance by having all of the binaries that run from /bin, /usr/bin, etc running on one drive and those that run from /opt or from /usr/local running from the second drive. I'm also assuming that we would want to load the oracle binaries/libraries in something like /opt/oracle or /usr/local/oracle on the "son of rosen" machine. 15 GB for /var for extensive logging .... While these sound like bizarrely large partitions, I'm not sure that I can think of additional partitions that we need to add here ... the only option would be to leave a few GB unpartioned on either drive in case we need some future expansion (6 GB swap, 12 GB /opt, 12 GB /var, 6 GB "in reserve"). Of course, then we need to plan for the partitioning of the A1000. I think that we need room for /db1, /db2, and /db3 from rosen. And for /home/Devel from guilden. And for /home/User from sunray. (Note: I'm not necessarily recommending that we need to preserve these names ... I'm guessing that a more common naming convention would be to call them something like /export/home/Devel on the A-1000 that gets mounted on to the other machines as /home/Devel ... but I may be confused.) What else do we need to store there for better availability? Would we want /var/spool/mail from snf so that we have everyone's inbox ... people seem most grumpy when they can't get e-mail. We may want to have the Web server (well, the repository of pages, not the server) there? How about the e-mail archives? Am I correct in thinking that we are hoping to store everything that represents "data" ... whether it is our actual database, home directories, e-mail storage, etc? Thought? Thanks, John From bmurray at snf.stanford.edu Fri Jan 11 08:49:04 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 11 Jan 2002 08:49:04 -0800 (PST) Subject: cvs works great! Message-ID: John, CVS works great! However, it appears to rely upon the OS password only. So I'm wondering how it determines who in the snf password file gets access to the repository. I'll take a look at this when I get in. I'll also call Tom at MIT so that he won't have any excuses for not moving forward on the Coral install. Finally, I'm beginnning to wonder if the Coral bug is not a subtle threading issue (which I've believed all along-> mine or Sun's). Adding the print statements may be just enough to slow things up so the problem doesn't occur. Thanks, Bill From bmurray at snf.stanford.edu Mon Jan 14 13:10:15 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 14 Jan 2002 13:10:15 -0800 (PST) Subject: Meeting at SNF Feb 4? In-Reply-To: Message-ID: Todd, That sounds great. John Shott, Mike Bell, and I will all be available. The agenda looks good. Please remind me to send you a parking permit. Thanks, Bill PS I haven't forgotten about the CVS accounts. I got sidetracked with an urgent problem. I'll get your accounts set up today or tomorrow. On Mon, 14 Jan 2002, Todd Merport wrote: > Hi Bill, > > It was nice talking to you again... > I would like to propose February 4 as the date for our visit to SNF. > We have the following staff slated to visit: > Katalin > Ferenc Varju (programmer) > T.K. Chen (50% programmer for the microlab; 50% for the bcam group) > plus > myself. > > >From our phone converstaton the other day I guess our agenda will be > something like: > a CORAL demonstration > discussion of the CORAL implementation > discussion of CORAL for the Microlab (wants, musts) > understanding/coordinating site specific customization of CORAL > (using Makefiles/Inheritance/Stored Procedures?) > > I think we will arrive mid-morning and leave mid-afternoon like our visit in > May 2000. > > Let me know if this day works out for you. > When the date is firmed up, we will need a parking permit. > > Todd > (510) 642-0294 > > > From bmurray at snf.stanford.edu Mon Jan 14 14:25:59 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Mon, 14 Jan 2002 14:25:59 -0800 (PST) Subject: SANS Securing Linux Message-ID: Mike, I borrowed the SANS Securing Linux book from your office. Thanks, Bill From bmurray at snf.stanford.edu Tue Jan 15 01:40:56 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 15 Jan 2002 01:40:56 -0800 (PST) Subject: Bug Fix Installed Message-ID: John, As usual the bug fix turn out to be a little more complicated than I had anticipated. After reviewing all the options we discussed, I was able to implement one of them. Although it was not the final one we discussed, I think it will work well. I will talk to you tomorrow about the problems I encountered with the approaches that involved modifying the tables and the adapters. (Basically, it required violating many of the consistent naming priciples that we spent so much time fixing late last year. Also, the code would have been very confusing to work with.) I have saved the code with all the debugging output in /home/labnet/.prod-install/labnet-debug-2002-01-14. I checked out a new copy of everything under labnet including the bug fixes. I restarted the servers at about 1:30am. Let's see how it goes. I certainly believe we have identified and fixed a major problem. Let's hope there aren't any others. Good night, Bill From shott at snf.stanford.edu Tue Jan 15 12:28:22 2002 From: shott at snf.stanford.edu (John Shott) Date: Tue, 15 Jan 2002 12:28:22 -0800 Subject: JDE for GNU emacs and Xemacs ... Message-ID: <3C4490E6.860E31A7@snf.stanford.edu> Bill and Mike: I beleive that I now have JDE working for both Xemacs and GNU emacs on guilden. It turns out that the byte-compiled LISP code is no longer compatible between GNU emacs and Xemacs ... I think that it must have been in the past because we only had it installed on once location. For reference, in the old days all of the JDE stuff (including the other things that it requires like speedbar ...) were stored in /usr/local/share/emacs/site-lisp. In now have created a "separate but equal" version of all of this stuff in /usr/local/lib/xemacs/site-lisp where I have byte compiled this stuff under Xemacs. In order for this to load the proper stuff, I have had to modify the .emacs file so you probably want to copy ~shott/.emacs into your home directory. Note: because this .emacs file will be used by all of our machines, I've modified the installation on sunray/rosen/bopeep so they duplicate this structure. Apparently, the old versions of xemacs and GNU emacs had compatible byte-compiled LISP ... in any event, this should now work everywhere. When it is time to load xemacs on sunstar and friends, I should probably handle this as it is probably the least friendly installation of any that I have tackled ... Happy editing ... John From bmurray at snf.stanford.edu Wed Jan 16 12:02:19 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 16 Jan 2002 12:02:19 -0800 (PST) Subject: Coral CVS Repository Message-ID: We have just finished testing and installing version 1.43 of Coral here at Stanford. So now is a good time to give developers at other institutions access to the Coral source code. 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. To get everyone, started I have set up a single CVS login named coral with read-only access to the repository. I will give developers secure Unix accounts on snf.stanford.edu when they need write-access. Here's how to get access quickly right now. 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:coral at snf.stanford.edu:/home/src 3) At the prompt, type "cvs login". You will be prompted for the password Please call me at (650) 725-3639 for the password. If I don't answer, leave a message and I will leave the password on your voicemail. (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 which happens to be tagged as "coral-1_43". 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 From shott at snf.stanford.edu Thu Jan 17 09:33:08 2002 From: shott at snf.stanford.edu (John Shott) Date: Thu, 17 Jan 2002 09:33:08 -0800 Subject: Proposed Makefile mods .... Message-ID: <3C470AD4.98EF556A@snf.stanford.edu> Bill and Mike: In an effort to cleanup (and make more easily configurable) our Makefiles, I'm considering the following changes. Before I get too far along, I want to make sure that the things that I'm considering sound reasonable and also to see if there are things that you would like to behave differently than they currently do. Here are some of the things that I would like to do: 1. Put all makefile "local configuration" parameters in one location. Currently calling the toplevel makefile (labnet Makefile) has definitions for PREFIX=/usr/local/coral ... and a bunch of other local configurations kinds of things. Also, all lower lever make files (in labnet/admin/server, for example) have an include statement that reads "include $(DEPTH)/labnet/etc/Makefile. etc/Makefile redefines many of these same varialbles and also includes many of our definitions for implicit rules. To fix this, I would propose splitting /etc/Makefile into 2 or 3 different files: call one "MakeRules", the second "config_default" and the third "site_specific/config,stanford" MakeRules (and the top level Makefile) would first include "config_default" and then include "site_specific/config,$(SITE)". Note: we already expect (and test) that each place has the environment variable SITE set to stanford, mit, berkeley, etc. In this way, each site need only modify one file (site-specific/config,$(SITE)) to determine where make will look for things, where make will install things, etc. (Note: I'm not talking here about the config files that determine how the clients and servers themselves behave .... that is another issue). 2. Straighten out confusion in etc and config directories. At the moment, the server and client config files are installed in /usr/local/coral/etc ... which is, to me, quite reasonable as one typically finds configuration files in etc. However, because we use labnet/etc (at present) for our makefile configuration stuff ... the $(BUILD_ETCDIR) is defined to be labnet/config (becuuse labnet/etc is already in use). I think that it makes more sense to move the "makefile definition and config stuff" from labnet/etc into labnet/config (which is also, I think) a bit more consistent with what one would expect with many GNU packages) and then use labnet/etc as the B(BUILD_ETCDIR) ... which is the place where the client and server configuration files are stored. Confused? 3. I think that I need to add the capability to rsync files to other machines ... this would avoid the need to manually copy things to snf, for example. "make install" or "make remote-install" should take care of that automatically. This will take some work, but, I think that it needs to be done. 4. Sort out "development" vs. "production" version stuff ... at the moment, if we aren't on a production environment, some of the installed things ... but not all of them ... have a "-dev" suffix. While it might take some work, I'm inclined to think that it might make sense to actually set it up so that all of the development stuff has "-dev" added ... Thoughts, comments, suggestions, things that you'd like to have happen differently? Thanks, John From bmurray at snf.stanford.edu Thu Jan 17 09:43:02 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 17 Jan 2002 09:43:02 -0800 (PST) Subject: Best location for various jar or zip files? In-Reply-To: <3C46303B.A7505425@snf.stanford.edu> Message-ID: John, If I remember correctly, anything that is actually part of the JDK would go in /usr/j2se/lib. Anything that is a runtime extension would go into /usr/j2se/jre/lib/ext/. The difficulty is that things like the JCE started out as an extension and are now part of the JDK. This happens frequently. Now retroguard is not part of the JDK or an extension of the JDK so it technically shouldn't be placed in either of these locations. Of course, we can do whatever we feel is appropriate. I don't have strong feelings, but I might place jdbc.zip in /usr/j2se/lib cause it's part of the JDK? The aba stuff is more difficult. If we place it in /usr/j2se/lib, we might write over Sun's implementation of the JCE which is now part of the JDK. Finally ZKM, could be placed in /usr/j2se/ jre/lib/ext/. I guess I haven't been much help on this one. Thanks, Bill PS Coral appears to be going strong after 58 hours. On Wed, 16 Jan 2002, John Shott wrote: > Bill: > > In looking at the makefiles, I realize that we are storing some of our non-Sun > jare files in some strange places ... and we shold probably clean them up. > > For example, jdbc.zip is in /app/java/lib/jdbc.zip > Our aba provider is in /usr/j2se/jre/lib/ext/jce.zip > When we used retroguard, retroguard.jar was in /usr/j2se/jre/lib/ext/jce.zip > and now that we use ZKM, zkm.jar is in /app/solaris/2.6/xkm/ZKM.jar. > > My initial thought is that they should all likely be in either /usr/j2se/lib > or in /usr/j2se/jre/lib/ext ... do you have a recommendation? > > Note: If I change any locations, I will likely copy rather than move them so > that existing makefiles won't break ... but if we have a new, makefile that > looks for them in standard locations, that it will work as well. > > Thanks, > > John > From bmurray at snf.stanford.edu Thu Jan 17 10:01:44 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 17 Jan 2002 10:01:44 -0800 (PST) Subject: Proposed Makefile mods .... In-Reply-To: <3C470AD4.98EF556A@snf.stanford.edu> Message-ID: John, Although my knowledge of make is pretty shallow. I'll throw in my two cents. See my comments below. Thanks for taking care of this, Bill On Thu, 17 Jan 2002, John Shott wrote: > > Here are some of the things that I would like to do: > > 1. Put all makefile "local configuration" parameters in one location. > This sounds good. I have found these redefinitions confusing in the past. > > 2. Straighten out confusion in etc and config directories. At the moment, the > server and client config files are installed in /usr/local/coral/etc ... which > is, to me, quite reasonable as one typically finds configuration files in etc. > However, because we use labnet/etc (at present) for our makefile configuration > stuff ... the $(BUILD_ETCDIR) is defined to be labnet/config (becuuse > labnet/etc is already in use). > > I think that it makes more sense to move the "makefile definition and config > stuff" from labnet/etc into labnet/config (which is also, I think) a bit more > consistent with what one would expect with many GNU packages) and then use > labnet/etc as the B(BUILD_ETCDIR) ... which is the place where the client and > server configuration files are stored. Confused? > I'll defer to your judgement on this one. As long as we're consistent, and I know where to find the client and server configuration files. > 3. I think that I need to add the capability to rsync files to other machines > ... this would avoid the need to manually copy things to snf, for example. > "make install" or "make remote-install" should take care of that > automatically. This will take some work, but, I think that it needs to be > done. This would be really great! I do most of the installs and am quite familiar with where things go, but I've goofed here in the past. I think that other institutions must have this feature or they'll never get client, remote client, and server code installed in the correct locations. > > 4. Sort out "development" vs. "production" version stuff ... at the moment, if > we aren't on a production environment, some of the installed things ... but > not all of them ... have a "-dev" suffix. While it might take some work, I'm > inclined to think that it might make sense to actually set it up so that all > of the development stuff has "-dev" added ... The current approach is a mess. It relies on undocumented environment variables, and I don't know what else. Although I don't know what the best approach is, almost anything will be better than the what we have now. There should never be any confusion about which version (prod vs dev) one is building or running. From shott at snf.stanford.edu Mon Jan 21 09:39:39 2002 From: shott at snf.stanford.edu (John Shott) Date: Mon, 21 Jan 2002 09:39:39 -0800 Subject: Makefile changes ... Message-ID: <3C4C525B.8BB40FBA@snf.stanford.edu> Bill and Mike: I've made a significant number of changes to the Makefiles and build environment. Although they are not yet checked in, it will result in all of the Makefiles being downloaded and upgraded ... and a few other changes. 1. I've renamed labnet/etc/Makefile to labnet/etc/MakeRules. Both labnet/Makefile (the top-level) makefile and anything that calls labnet/etc/MakeRules (which includes, I think, all lower level makefiles) then include labnet/etc/config_default followed by including labnet/etc/site-specific/config,stanford. Well, in general, the included file is labnet/etc/site-specific/config,$(SITE). As a result all default configuration of the build process is controlled in config_default and any local over-ride of any of these values is in site-specific/config,stanford. So, any new site should be able to look at what is set in config_default and decide what they need to override in site-specific/config,THEIR_SITE. 2. I've eliminated that pesky "PRODUCTION_ENV" variable ... $(SITE) is the only environment variable that needs to be defined ... and that, I think, may need to be done unless there is a way that I can determine the domain name automatically. 3. Development machines are specified in labnet/etc/site-specific/config,stanford: DEVELOPMENT = guilden bopeep Note: names should be in the form that "uname -n" returns them. Also, I can specify NO_SERVER, NO_CLIENT, NO_INTERLOCK sot that a "make all" will only make clients if that machine is specified in NO_SERVER. So, for us we have specified: NO_SERVER = sunray sunstar bopeep Note: the NO_INTERLOCK flag is for machines that won't have a daemon/driver. We don't specify anything for that because it is smart enough to automatically add NO_INTERLOCK for any machine that is not a Linux machine. Note: I don't yet have the build/install process for the daemon and driver in place, but we will need it before we completely release things. 4. I've more completely separated development from production versions: if it is a development machine, all of the jar files are named things like equipment-client-dev.jar, etc. The configuration files are named things like labnet-dev.conf, and the "run-scripts" are named labnet-dev, coral-dev. servers-dev, and servers_start-dev. I think that this will be clearer and will make it possible to do things like run a production client against a development server. (This would be done, I think, by saying "make DEVEL=yes client-install" on rosen in a labnet directory that had some client modifications that needed to be tested ...). Note: on a machine that does not have any production stuff ... such as guilden ... even though it installs labnet-dev, coral-dev, servers-dev, and servers_start-dev, it creates links named labnet, coral, servers, and servers_start (it checks to make sure that there are no files ... which would be a "production installation" before making those links. Once question that I have ... we have always installed the "client script" as labnet and then made a link called coral. I think that it would make more sense to just have one script called coral ... making a link called coral gets confused with the idea of making a link named coral to coral-dev. Plus, anywhere but with us old-timers, "coral" is going to be the more natural thing to call our client. 5. I've got a start on some of the rsync stuff. I think that "make remote-install" now copies everything to the appropriate place on snf. It actually does this for both the jar files (in the lib directory) and the jnlp files (and even the coral_icon.jpg file in the etc directory). It is set up so that it checks file size and the 128-bit MD4 checksum before copying. This, I think, will make sure that we only update those remote files that have actually changed so that folks won't necessarily have to download any unecessary stuff. Note: it is also set up so that rsync uses ssh. At the moment, I think, rsyncy will propmt for the root password on snf twice (one when it updates the etc directory and once when it updates the lib directory). If I get a little smarter about distributing some of the keys for ssh, this password entry may be eliminated. Note: I haven't fully tested this because I didn't want to mess with the production stuff. Bill, maybe if you are in today, we can test this on guilden to see if all of these build/install changes work properly. There are still a few things to be done: 1. At some point, we need to have the makefile be able to make the keystore. I think that we currently use an existing keystore to sign our jar files. 2. At the moment, we currently store the AdminServerIOR in a "tricky" place that is cross-mounted across several machines. This is unlikely to work elsewhere. I think that we store it in something like /home/labnet/share/IOR/AdminServerIOR. More natural naming would be to install it in /usr/local/coral/share/IOR/AdminServerIOR (and probably /usr/local/coral/share/IOR/AdminServerIOR-dev ...) and then use rsync (if we can eliminate the need to enter root passwrod) to rysnc it to any other machines or websites that need to know it. I see no reason that the servers script can't be modified so that it (1) starts the AdminServer (2) rsyncs the IOR where it needs to be ... (3) starts the remaining servers. 3. I think that we should be close to being able to do a "make install" on rosen that not only makes everything that it needs but is smart enough to rsync the appropriate client stuff to sunray (and, soon, sunstar). This would avoid the tedious process of doing a make install on rosen, then doing a make client-install on sunray, a make client-install on sunstar and then going back to rosen to start the servers. That doesn't yet work, but it is, I think, a good thing to have available. Comments, criticisms, things you'd like to see? Things you'd like to remove? Thanks, John From shott at snf.stanford.edu Wed Jan 23 08:28:03 2002 From: shott at snf.stanford.edu (John Shott) Date: Wed, 23 Jan 2002 08:28:03 -0800 Subject: Java 1.4.0 Release Candidate .... Message-ID: <3C4EE493.AEB1CC12@snf.stanford.edu> Bill and Mike: I've installed the 1.4.0 Release Candidate of J2SE on rosen, sunray, bopeep, and guilden (including all required OS patches that seem to accompany each release). Additionally, on each machine I've moved /usr/j2se/jre/lib/jce.jar to /usr/j2se/jre/lib/jce.jar.ignore ... this is required because we use the ABA jce provider instead of the sun default. Just as a note, because the root partition on bopeep is getting pretty full, I didn't install the man pages (SUNWj3man) or the demo stuff (SUNWj3dmo) associated with J2SE 1.4.0-rc. I also remove one of the old JDKs that had been installed on bopeep to allow enough room to apply the patches and install the essential elements of J2SE. Even at that, there is only about 5 MB left on the root partion on bopeep ... Thanks, John From mtang at snf.stanford.edu Wed Jan 23 09:50:20 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Wed, 23 Jan 2002 09:50:20 -0800 Subject: snf computer account References: Message-ID: <3C4EF7DB.9E44C95@snf.stanford.edu> Hi Jawad -- I'm forwarding your message to Ciara Preston, who sets up new accounts, and to the email list "coral at snf" which handles all coral-related problems. Please let me know if there are any problems -- Mary Jawad Nasrullah wrote: > Hi Mary, > > Can you please forward my question to system administrator of coral/snf. > I could not figure out who has that responsibility. > > I can login at coral terminals in lab fine with my password. However when > I try to ssh snf.stanford.edu, it does not accept my password. Can you > please let me know how this can be fixed? > > my croal login is 'jawad' > > Thank you very much. > > -jawad -- 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 Wed Jan 23 18:25:23 2002 From: mtang at snf.stanford.edu (Mary Tang) Date: Wed, 23 Jan 2002 18:25:23 -0800 Subject: Coral Down Message-ID: <3C4F7093.BB242A55@snf.stanford.edu> Hi Coral guys -- I just got a report that people are not able to log into Coral -- people can log onto the SUN station just fine, but the Coral screen just doesn't come up... Help? -- 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 Jan 23 19:25:12 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 23 Jan 2002 19:25:12 -0800 (PST) Subject: Coral Down In-Reply-To: <3C4F7093.BB242A55@snf.stanford.edu> Message-ID: Mary, I restarted the servers at about 7pm. Everything should be fine now. I was busy coding and didn't see your message until just now. Thanks, Bill On Wed, 23 Jan 2002, Mary Tang wrote: > Hi Coral guys -- > > I just got a report that people are not able to log into Coral -- people > can log onto the SUN station just fine, but the Coral screen just > doesn't come up... Help? > > -- > 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 ycfu at attbi.com Sat Jan 26 08:44:20 2002 From: ycfu at attbi.com (Y.C Fu) Date: Sat, 26 Jan 2002 08:44:20 -0800 Subject: Need help to use Coral Message-ID: Hi, I am a new user of the Remote Coral Access. I installed the Java Web Start, launched the Coral Access and received the following error message: "An error occurred while launching/running the application. Title: Coral Remote (SNF) Vendor: Stanford Nanofabrication Facility Category: Security Error Unsigned application requesting unrestricted access to system" My system is Windows 2000. I use att broadband internet service. Please help me solve this problem. Many thanks. Y.C. Fu From bmurray at snf.stanford.edu Wed Jan 30 18:45:07 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 30 Jan 2002 18:45:07 -0800 (PST) Subject: Parking Permit for Visit on the 4th. In-Reply-To: Message-ID: Todd, I just now mailed the parking sticker. If you don't receive it in time, then park behind the CIS Building in one of the spaces marked for vendors/contractors. Then enter the building through the loading dock. There's a parking sign-in sheet. Just note on there that you're here to see John Shott. Thanks, Bill From bmurray at snf.stanford.edu Thu Jan 31 10:45:21 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 31 Jan 2002 10:45:21 -0800 (PST) Subject: Qualification question (problem?) In-Reply-To: Message-ID: Nancy, You are correct that he is qualified on stsetch. However, I have checked the logs. The user 'bergevin' has not logged in locally since July 28, 2000, and his last login remotely occurred sometime before January 23. I don't understand how he could have enabled the stsetch if he hasn't logged in? Something is not right here. Does he have another login name that he uses? Bill On Thu, 31 Jan 2002, Nancy Latta wrote: > Guys- > > I qualified a user, bergevin, on stsetch yesterday and although his > qualification is in the system, he is unable to enable to etcher (no star > either...) > > Thanks, > > Nancy > From bmurray at snf.stanford.edu Thu Jan 31 10:48:19 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 31 Jan 2002 10:48:19 -0800 (PST) Subject: Qualification question (problem?) In-Reply-To: Message-ID: Nancy, Here's the problem. The user Joe Bergevin has two active Coral accounts. One is 'bergevin'. The other is 'joeb'. We need to make sure that Ciara doesn't set up a second user when the user already has an account. Thanks, Bill On Thu, 31 Jan 2002, Bill Murray wrote: > Nancy, > > You are correct that he is qualified on stsetch. However, I have checked > the logs. The user 'bergevin' has not logged in locally since July 28, 2000, > and his last login remotely occurred sometime before January 23. I don't > understand how he could have enabled the stsetch if he hasn't logged in? > Something is not right here. Does he have another login name that he uses? > > Bill > > On Thu, 31 Jan 2002, Nancy Latta wrote: > > > Guys- > > > > I qualified a user, bergevin, on stsetch yesterday and although his > > qualification is in the system, he is unable to enable to etcher (no star > > either...) > > > > Thanks, > > > > Nancy > > > From bmurray at snf.stanford.edu Thu Jan 31 12:41:49 2002 From: bmurray at snf.stanford.edu (Bill Murray) Date: Thu, 31 Jan 2002 12:41:49 -0800 (PST) Subject: Setting up Coral and Postgres Message-ID: John and Mike, Here are my notes on how to set up and configure Coral running on Postgres. Bill 1) Create a disk partition greater than or equal to 2GB. [root at shott /dev]# fdisk /dev/hda Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 784 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 3 24066 83 Linux /dev/hda2 4 784 6273382+ 5 Extended /dev/hda5 4 20 136521 82 Linux swap /dev/hda6 21 784 6136798+ 83 Linux 2) Mount /usr/local/coral/data on the partition. 3) As root, create a directory for the Coral database, make postgres the owner, and initialize the database storage area. [root at shott local]# pwd /usr/local [root at shott local]# mkdir coral [root at shott local]# cd coral [root at shott coral]# mkdir data [root at shott coral]# chown postgres /usr/local/coral/data [root at shott coral]# su postgres bash-2.04$ initdb -D /usr/local/coral/data This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Fixing permissions on pre-existing data directory /usr/local/coral/data Creating database system directory /usr/local/coral/data/base Creating database XLOG directory /usr/local/coral/data/pg_xlog Creating template database in /usr/local/coral/data/base/template1 Creating global relations in /usr/local/coral/data/base Adding template1 database to pg_database Creating view pg_user. Creating view pg_rules. Creating view pg_views. Creating view pg_tables. Creating view pg_indexes. Loading pg_description. Vacuuming database. Success. You can now start the database server using: /usr/bin/postmaster -D /usr/local/coral/data or /usr/bin/pg_ctl -D /usr/local/coral/data start bash-2.04$ 4) Edit /usr/local/coral/data/postgresql.conf to allow TCP/IP connections and use port 5432 by adding tcpip_socket = true port = 5432 5) The database server is called postmaster. To start the postmaster in the background from the command line: /usr/bin/postmaster -D /usr/local/coral/data -i > /var/log/labnet/db.log 2>&1 & Make sure to create/modify /etc/init.d/postgresql to properly start and stop your database when the system is rebooted. (Note -i allows TCP/IP connections to the database.) 6) Login as root and su to postgres. Create the labdba user by issuing the following "createuser -d -a -P labdba" When prompted, enter the labdba password. You will need this when you run the Makefile which creates the managers and tables. Then create the database by typing "createdb -U labdba lab 'Coral Database'" [root at shott /root]# su - postgres bash-2.04$ createuser -d -a -P labdba Enter password for user "labdba": Enter it again: CREATE USER bash-2.04$ createdb -U labdba lab 'Coral Database' CREATE DATABASE COMMENT 7) As postgres, install the Postgres procedural language into the Coral database. createlang plpgsql lab 8) If you have not already done so, set the Postgres password for the postgres user. bash-2.04$ psql lab postgres Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit lab=# alter user postgres with password 'secure'; ALTER USER lab=# 9) Client authentication is controlled by the file pg_hba.conf in /usr/local/coral/data. Set the appropriate authentication method. For example, the following lines require password authetication for all databases over UNIX domain sockets and localhost and behind the firewall. local all password host all 127.0.0.1 255.255.255.255 password host lab 192.168.0.0 255.255.0.0 password 10) Then type "make clean" and "make all".