20030930: upgrade LDM from 5.2 to 6.0.14 (cont.)

>From: "Alexander Clark" <address@hidden>
>Organization: Yale
>Keywords: 200309300733.h8U7XIk1021618 LDM upgrade

Alexander,

>I'm passing along our authentication credentials to facilitate the LDM
>upgrade at Yale.
>
>Thank you!

I got the login info and have been on your machine for awhile this
morning.  I found a number of problems that prevented me from building
the LDM-6 from source:

- the permissions set for directories like /bin, /usr/bin, etc. were
  such that the user 'ldm' could not even run a simple Unix command
  like 'ls'.  Entries in /var/log/messages shows that the setting
  of directory permissions is automated:

Sep 30 14:01:09 martindale msec: changed mode of /usr/src from 755 to 751
Sep 30 14:01:09 martindale msec: changed mode of /boot from 754 to 710
Sep 30 14:01:09 martindale msec: changed mode of /lib from 755 to 751
Sep 30 14:01:09 martindale msec: changed mode of /usr/share from 755 to 751
Sep 30 14:01:09 martindale msec: changed mode of /usr/games from 755 to 751
Sep 30 14:01:09 martindale msec: changed mode of /bin from 755 to 751
 ...

- it appears that your OS (Mandrake 9.1 Linux) has been setup so that
  'ldm' is not allowed to run scripts.  Here is an example log
  entry from /var/log/messages:

Sep 30 13:10:38 martindale kernel: grsec: From 128.117.140.45: denied exec of 
./configure by (tcsh:7244) UID(502) EUID(502), parent (tcsh:31102) UID(502) 
EUID(502) reason: untrusted

  As a consequence, someone there decided to run the LDM as 'root'.  This
  is diametrically opposed to how we feel that the LDM should be run,
  and it may open a security breach.

- even if 'ldm' could run scripts, the development environment needed
  to bulid the LDM from source did not fully exist (yacc, for one
  is not installed on your machine)

- the system clock on martindale is off, and it appears that you are
  not running either ntpd or ntpdate to set it on a regular basis.
  It is important to keep an accurate clock so that you can continue
  to get real time data.  I strongly recommend that you run ntpdate
  at least once-per-hour from 'root's cron.  Here is an example
  cron invocation that points at a timeserver named 'timeserver

0 * * * * /usr/sbin/ntpdate timeserver > /dev/null

  Since I could not find ntpdate on your machine, you will need to
  install it from rpms for your Linux distribution.


The above problems lead to some questions:

1) why is 'ldm' not allowed to run scripts

2) why are the permissions on various directories that contain executables
   being set so that nobody by 'root' can run them?

3) can someone there setup the running of ntpdate to set the clock at
   least once-per-hour

How things stand at the moment:

- I built a binary LDM-6.0.14 on a RedHat 9.0 Linux machine here at
  the UPC and installed it in the ~ldm directory.

- I changed the runtime link in /usr/local/ldm to point at ldm-6.0.14
  (it was pointing at ldm-5.2)

- given the directory permission changing being done, the only way to get
  the LDM running was to run it as 'root' (as it was running before I
  logged on).  I can tell you that I don't think that this is a good
  situation.

- given that there is no cron job running to report pqbinstats stats
  to Unidata, I commented out the 'exec pqbinstats' line in ~ldm/ldmd.conf

- finally, I changed the machine that martindale is requesting its
  IDS|DDPLUS feed from to atm.geo.nsf.gov.  We may ask you to change
  this request in the (near) future as we reorganize the IDD topology.

Please let me know if you have questions about what I did, or see
anything amiss on martindale.

Tom Yoksas