20000802: McIDAS-X ADDE and LDM installation at Western Michigan (cont.)

>From: "John D. Tucker" <address@hidden>
>Organization: Western Michigan
>Keywords: 200007181435.e6IEZAT22632 McIDAS-X -XCD ADDE LDM install

John and Elen,

Elen, please read this message and make the decision regarding deletion
of AREA files in ~mcidas/mcidas/data called for below.

John,

There are two topics in this email:  me finishing up the installation
and test of the McIDAS remote ADDE server, and three modifications that
need to be made by 'root' to get the LDM working

Here goes:

re: mcadde and mcidas having the same home directory

>We could probably jury-rig something such that mcadde and mcidas would 
>share a home directory, but (apparently) this was not understood.  I 
>will look into hassles of doing this tomorrow as I am already late for
>exiting this place tonight and need to get home.

Yesterday John changed the permissions on ~mcadde and ~mcidas were
changed so that all group members can read these directories.
This was all that was needed for me to finish up getting the McIDAS
remote ADDE server working on s418.  I can't access this server from
the outside world, but I assume that this configuration was done
by design; I can live with it.  On a positive note, I am able to
exercise the remote ADDE server from the 'mcidas' account.  The only
problem I ran into was a McIDAS executable that was munged.  The
problem went away when I deleted the executable (adirserv) and
remade it.  This may have been a problem that was created by the
build dying when I exceeded disk quotas, but the build log file
doesn't support this.  I may rebuild and install the entire distriubtion
overnight just to make sure...

>s418 is a workstation with some local disks (/ilya1.../ilya3 if memory
>serves).  Generally, the storage allocated to an account is on a
>fileserver (Grog) with the accounts living on "/home7" along with other 
>users and software.

Yes, I knew that.

>SU:/home7/ldm> df -k /home7
>Filesystem            kbytes    used   avail capacity  Mounted on
>/dev/dsk/c1t2d0s0    20492201 13471486 6815793    67%    /home7

>I have increased the quota for "mcidas" to 500k blocks.  When I checked 
>the account, the account as already over quota.  Bearing in mind that the
>disk is shared with other users (see above), I can increase it a bit more
>if necessary.  Please keep me advised of needs and I will see what can be
>done (at least until Leonard returns).

There will be no great increase in disk usage from the McIDAS installation.

Just over 100 MB space used in the account can be recovered by deleting the
AREA files in the ~mcidas/mcidas/data subdirectory, but Elen will have to make
this decision

Elen,

The AREA files in ~mcidas/mcidas/data _seem_ for the most part seem
to be duplicates of ones in /ilya2/mcidas/data:

ls -lt ~/mcidas/data/AREA6239 /ilya2/mcidas/data/AREA6239
-rw-r--r--   1 mcidas   ldm      39266488 Jul 27 16:13 
/ilya2/mcidas/data/AREA6239
-rw-r--r--   1 mcidas   ldm      39266488 Jul 25 17:27 
/home7/ldm/mcidas/mcidas/data/AREA6239
~/workdata> cmp ~/mcidas/data/AREA6239 /ilya2/mcidas/data/AREA6239
<no difference>

ls -lt ~/mcidas/data/AREA6240 /ilya2/mcidas/data/AREA6240
-rw-r--r--   1 mcidas   ldm      39266488 Jul 27 16:14 
/ilya2/mcidas/data/AREA6240
-rw-r--r--   1 mcidas   ldm      39266488 Jul 25 17:34 
/home7/ldm/mcidas/mcidas/data/AREA6240
~/workdata> cmp ~/mcidas/data/AREA6240 /ilya2/mcidas/data/AREA6240
<no difference>

The third file, AREA6241, on the other hand, is different:

-rw-r--r--   1 mcidas   ldm      49017488 Jul 27 16:18 
/ilya2/mcidas/data/AREA6241
-rw-r--r--   1 mcidas   ldm      35684352 Jul 27 16:02 
/home7/ldm/mcidas/mcidas/data/AREA6241

If the files in ~mcidas/mcidas/data are really duplicates of the ones
in /ilya2/mcidas/data, then they should be deleted.


John again,

>Disk quotas for ldm (uid 3081):
>Filesystem     usage  quota  limit    timeleft  files  quota  limit
>timeleft
>/home7         78144 147000 150000               1255  14990  15000           
>  
>Disk quotas for mcadde (uid 7319):
>Filesystem     usage  quota  limit    timeleft  files  quota  limit
>timeleft
>/home7          2273   7350   7500                 40    740    750           
>  
>Disk quotas for mcidas (uid 5453):
>Filesystem     usage  quota  limit    timeleft  files  quota  limit
>timeleft
>/home7        399996 490000 500000               7604  49990  50000 

I understand.

re: users in a group not being able to access each other's directories

>When an account is created, we automatically protect the home directory
>as 700 (or something close to that).  This limits the possibilities of
>students "borrowing" work from another student in the same class.  I have
>changed the protections on the three accounts such that the group (ldm)
>should have read and search privileges for all three accounts.

>SU:/home7/ldm> ls -l
>total 10
>drwxr-s---  20 ldm      ldm         3072 Aug  2 15:40 ldm
>drwxr-s---   6 mcadde   ldm          512 Aug  2 15:15 mcadde
>drwxr-s---  19 mcidas   ldm         1024 Jul 25 15:21 mcidas
>
>I should be in at 8 a.m. (EDT) tomorrow and generally around.  Please call
>or e-mail if the above actions are inadequate.  Got to run....

Excellent.  This is what I needed to get things working.  Thanks!

Now, onto the setup steps needed to be done by 'root' to get the LDM
working.  Here are snippits of our online instructions for installing/
configuring the LDM:

Configuring the Operating System as root
http://www.unidata.ucar.edu/packages/ldm/ldmPreInstallList.html#s8

Configuring the Operating System as root

     Add the following lines to file /etc/services 

                 ldm 388/udp unidata        # UCAR Unidata LDM
                 ldm 388/tcp unidata        # UCAR Unidata LDM
            

     This allows programs such as netstat to associate activity on IP port 388
     with the LDM.

     Add the following line to file /etc/rpc 

                 ldmd 300029 ldm
            

     This allows programs such as rpcinfo to identify RPC program number
     300029 as the LDM.

     The LDM uses the system logging daemon, syslogd, to write error messages
     by the local0 facility. 

         Add the following entries to file /etc/syslog.conf 

                local0.debug       /usr/local/ldm/logs/ldmd.log
                

         Modify the following lines in file /etc/syslog.conf so that LDM
          messages will not be written to the console 

         *.err;kern.notice;auth.notice;user.none;local0.none     /dev/console
         *.err;kern.debug;daemon.notice;mail.crit;user.none;local0.none  
/var/adm/message


Make rpc.ldmd and hupsyslog suid root
http://www.unidata.ucar.edu/packages/ldm/ldmBinaryInstallList.html#s7

Change permissions for rpc.ldmd and hupsyslog to be setuid root. This step
needs to be done as root 

             % cd ~ldm/{version-directory}/bin
             % chown root rpc.ldmd
             % chown root hupsyslog
             % chmod u+srwx,g+rx,o+rx rpc.ldmd
             % chmod u+srwx,g+rx,o+rx hupsyslog
            
Here {version-directory} will be ldm-5.0.8.

As soon as these changes are made, the LDM should be able to be started
and run to collect realtime data for Elen's classes.

Tom Yoksas