>From: Michael Keables <address@hidden> >Organization: DU >Keywords: 199909152035.OAA16060 LDM ldm-mcidas Mike, >First, thanks so much for all of your help with cyclone and the LDM. Being >a unix novice, I make a lot of mistakes and as such, I really appreciate >not only your assistance but the explanations as well. After I got your voicemail, we ran amok on cyclone :-) >Here's the deal with cyclone. It has two hard drives installed in it with >/export/home residing on one and everything else on the other: > > df -k >Filesystem kbytes used avail capacity Mounted on >/proc 0 0 0 0% /proc >/dev/dsk/c0t0d0s0 96455 40768 46042 47% / >/dev/dsk/c0t0d0s6 877790 665487 150858 82% /usr >fd 0 0 0 0% /dev/fd >/dev/dsk/c0t0d0s1 413639 250169 122107 68% /var >/dev/dsk/c0t1d0s7 8509324 339115 8085116 5% /export/home >/dev/dsk/c0t0d0s5 3007086 917816 2029129 32% /opt >/dev/dsk/c0t0d0s7 4031022 140916 3849796 4% /usr/local >swap 643192 400 642792 1% /tmp >> This was the original setup on cyclone. As you read through this email, you will see that things have changed (for the better). >Given the above, how do you suggest I deal with the matter of /var being >set to 400 MB? Just looking at the allocation, I can reduce the storage >allocated to /usr/local and transfer it to /var, or I can have the data >stored on /export/home which you indicated was a less desirable solution. Here is the implementation (i.e. what we did) of our recommendation: <login as ldm> ldmadmin stop <login as root> <move everything in /usr/local into /opt> cd /opt ufsdump 0f - /dev/dsk/c0t0d0s7 | ufsrestore rf - sync rm restoresymtable umount /usr/local newfs -i 8192 /dev/dsk/c0t0d0s7 <move everthing in /export/home to what was /usr/local> mount /dev/dsk/c0t0d0s7 /mnt cd /mnt ufsdump 0f - /dev/dsk/c0t1d0s7 | ufsrestore rf - sync cd /mnt rm restoresymtable cd / umount /mnt cd /etc <edit vfstab> change: /dev/dsk/c0t1d0s7 /dev/rdsk/c0t1d0s7 /usr/local ufs 2 yes - to: /dev/dsk/c0t1d0s7 /dev/rdsk/c0t1d0s7 /opt ufs 2 yes - Do the same thing for the entry for the /export/home entry in vfstab: change: /dev/dsk/c0t1d0s7 /dev/rdsk/c0t1d0s7 /export/home ufs 2 yes - to: /dev/dsk/c0t1d0s7 /dev/rdsk/c0t1d0s7 /data ufs 2 yes - reboot newfs -i 8192 /dev/dsk/c0t1d0s7 After this, what was /export/home will be empty. cd / mkdir /data mount /data mkdir /data/ldm mkdir /data/ldm/mcidas chown ldm:ldmgroup /data/ldm /data/ldm/mcidas chmod 775 /data/ldm/mcidas cp -p /var/data/mcidas/* /data/ldm/mcidas cd /var rm -rf data cd /usr/local/ldm rm data ln -s /data/ldm data ln -s /data/ldm/logs logs <login as 'ldm'> <edit etc/pqact.conf> change all occurrances of /var/data/mcidas to data/mcidas ldmadmin mkqueue touch data/logs/ldmd.log hupsyslog ldmadmin start You see, piece of cake ;-) This leaves you with the following disk configuration: cyclone# df -k Filesystem kbytes used avail capacity Mounted on /proc 0 0 0 0% /proc /dev/dsk/c0t0d0s0 96455 40767 46043 47% / /dev/dsk/c0t0d0s6 877790 665199 151146 82% /usr fd 0 0 0 0% /dev/fd /dev/dsk/c0t0d0s1 413639 22750 349526 7% /var /dev/dsk/c0t0d0s5 3007086 1058723 1888222 36% /opt /dev/dsk/c0t0d0s7 4031022 340533 3650179 9% /export/home swap 673024 16 673008 1% /tmp /dev/dsk/c0t1d0s7 8509324 180144 8244087 3% /data Now, you can put LOTS of data in /data/ldm... User's home directories will go into /export/home where there is plenty of room. /usr/local is now the same as /opt. There are several things you don't need and several security holes that we fixed for you. This was done by commenting out entries in /etc/inetd.conf as 'root': name (these are just annoying) uucp (these are just annoying) discard (these are just annoying) daytime (these are just annoying) chargen (these are just annoying) 100083/1 (tooltalk database is a known security problem) 100221/1 (KCMS Profiler Server is a known security problem) 100068/2-5 (calendar manager is a known security problem) kill -HUP 148 (148 is the process ID of inetd) >My current plan is to still have cyclone ingest and decode the data and >then to have students using the linux machines to access and display the >data products. This sounds like a good, usable plan. The next thing to do is to finish off the McIDAS installation: <login as 'mcidas'> cd mcidas7.6/update ftp ftp.unidata.ucar.edu <user> <pass> cd unix/760/bugfix bin get mcupdate.tar.Z quit ./mcunpack cd ../src make all make install.all cd ~/data cp EXAMPLE.NAM LOCAL.NAM cp DSSERVE.BAT LSSERVE.BAT cp DATALOC.BAT LOCDATA.BAT <edit LOCDATA.BAT and change all occurrences of fully_qualified_hostname to cyclone.natnet.du.edu> <edit LOCAL.NAM and set the directories for McIDAS data files to /data/ldm/mcidas> cd ~/workdata <start a McIDAS-X session> REDIRECT REST LOCAL.NAM TE XCDDATA "/data/ldm/mcidas BATCH XCD.BAT BATCH XCDDEC.BAT DECINFO SET DMGRID ACTIVE BATCH LSSERVE.BAT ROUTE REL C ROUTE REL N EXIT The TE XCDDATA... set of commands sets up the McIDAS environment for running of the XCD decoders. The BATCH LSSERVE.BAT line sets up the ADDE data sets for the remote ADDE server. The ROUTE REL commands enable the creation of composite images by way of ROUTE PostProcess BATCH invocations. This works because I configured ~ldm/decoders/batch.k yesterday. <edit mcscour.sh and set MCHOME to /export/home/mcidas. This sets up McIDAS data file scouring> setenv EDITOR vi crontab -e <add entry for scouring McIDAS data files> <login as 'ldm'> ldmadmin stop cd etc <edit ldmd.conf and add the entry: exec "xcd_run MONITOR" <edit pqact.conf and uncomment out the entries for XCD stuff that I added yesterday: # Entries for XCD decoders DDPLUS|IDS ^.* PIPE xcd_run DDS HRS ^.* PIPE xcd_run HRS Restart the LDM: ldmadmin start You now have XCD decoders producing McIDAS data files. The data will be scoured by virtue of the crontab entry above made as the user 'mcidas'. Your remote ADDE server is working; I was able to point to it and list and load data back to my machine here at Unidata. >Thanks in advance. You are welcome. There may be a couple of issues related to proper execution of some McIDAS commands. I have discovered a bug in the Sun SC5.0 Fortran compiler that affects several routines here at Unidata. I see that the same problem is showing up on your system by getting: PTLIST RTPTSRC/SFCHOURLY Row : 1 Col : 8 Program terminated, segmentation violation The other programs that will probably have problems are GRDCOPY and GRDDISP. I am working on finding a fix/workaround for the SC5.0 bug. >P.S. NLDN data are now being ingested as well as the mcidas and FSL2 >datastreams. OK, I see that: PTLIST RTPTSRC/PTSRCS.ALL FORM=FILE Pos Description Schema NRows NCols Date ------ -------------------------------- ------ ----- ----- ------- 9 SAO/METAR data for 16 SEP 1999 ISFC 72 4500 1999259 10 SAO/METAR data for 17 SEP 1999 ISFC 72 4500 1999260 19 Mand. Level RAOB for 16 SEP 1999 IRAB 8 1300 1999259 20 Mand. Level RAOB for 17 SEP 1999 IRAB 8 1300 1999260 29 Sig. Level RAOB for 16 SEP 1999 IRSG 16 6000 1999259 30 Sig. Level RAOB for 17 SEP 1999 IRSG 16 6000 1999260 39 SHIP/BUOY data for 16 SEP 1999 ISHP 24 2000 1999259 40 SHIP/BUOY data for 17 SEP 1999 ISHP 24 2000 1999260 59 SYNOPTIC data for 16 SEP 1999 SYN 8 6000 1999259 60 SYNOPTIC data for 17 SEP 1999 SYN 8 6000 1999260 69 PIREP/AIREP data for 16 SEP 1999 PIRP 24 1500 1999259 70 PIREP/AIREP data for 17 SEP 1999 PIRP 24 1500 1999260 79 NLDN data for 16 Sep 1999 NLDN 1000 1000 1999259 80 NLDN data for 17 Sep 1999 NLDN 1000 1000 1999260 89 Hourly Prof data for 16 Sep 1999 WPRO 48 35 1999259 90 Hourly Prof data for 17 Sep 1999 WPRO 48 35 1999260 99 6-min Prof data for 16 Sep 1999 WPR6 480 35 1999259 100 6-min Prof data for 17 Sep 1999 WPR6 480 35 1999260 PTLIST: Done I will look at your setup more tomorrow... Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.