[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IDD #VRK-635010]: idd data

Hi Marck,

re:
> ok ldmadmin watch works now.

Excellent!

re:
> but we have no luck with the log files still.

OK.

> can you ssh into the system?

I SSHed to your machine right after receiving this email.  Here
is what I found:

- for some reason, the runtime link in the HOME directory of 'ldm'
  was missing

  I recreated it as follows:

  <as 'ldm'>
  cd ~ldm
  ln -s ldm-6.11.6 runtime

  Now, the ~/bin directory is found, and that is important since that
  is how the LDM executables are found

- next, I verified that setuid root permission was set for the 'ldmd'
  and 'hupsyslog' LDM routines

  Very good.  This told me that the reason that logging might not be
  working was because the SELINUX setup had not been changed.

- I changed the SELINUX setup to allow LDM logging:

  <as 'root'>
  -- edit /etc/selinux/config and:

     change:
     SELINUX=enforcing

     to:
     SELINUX=disabled

  This change will become effective the next time the machine is rebooted.

  I forced SELINUX to change out of 'enforcing' mode to 'permissive' mode
  as follows:

  <as 'root'>
  # setenforce 0

  I verified the change with:

  # sestatus

  SELinux status:                 enabled
  SELinuxfs mount:                /selinux
  Current mode:                   permissive
  Mode from config file:          disabled
  Policy version:                 24
  Policy from config file:        targeted

  This will change to:

  SELinux status:                 disabled

  after a reboot.

- the final thing to be done at this point was to setup a boot-time script
  that will start the LDM upon reboot

  I did this by copying the reboot script that we use into the /etc/init.d
  directory and making sure that the read/write/execute permissions were
  correctly set.

  I exercised the script to make sure that it worked by running the following:

  <as 'root'>
  cd /etc/init.d
  ./ldmd stop
  -- verified that the LDM which had been running was stopped, OK

  ./ldmd start
  -- verified that the LDM was successfully started and was running as
     'ldm' ** NOT ** as 'root' (this is _important_)

- the next thing I found was that the clock on your machine was not being
  synchronized via ntpd

  It is very important that the system clock be kept accurate through the
  use of ntpd.  I forced your clock to synchronize and then setup ntpd to
  run as follows:

  <as 'root'>

  [root@dma etc]# ntpdate timeserver.unidata.ucar.edu
  29 Oct 17:14:35 ntpdate[6173]: step time server 128.117.140.2 offset 
174.832285 sec
  [root@dma etc]# chkconfig ntpdate on
  [root@dma etc]# service ntpdate start
  ntpdate: Synchronizing with time server:                   [  OK  ]

- the next thing I did was to hardware a fully-qualified hostname into the
  LDM registry file so that real-time stats reported by your machine would
  show up nicely on our real-time stats pages

  Your machine was known as dma.ldm; I changed it to dma.ldm.meteo.aw.

  Here is how you navigate our website to find the real-time statistics
  pages:

  Unidata HomePage
  http://www.unidata.ucar.edu

    Data -> IDD Operational Status
    http://www.unidata.ucar.edu/projects/idd/rtstats/

      Statistics by Host
      http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex

  If all goes well, your machine should show up in the listing on the
  past page as:  aw.meteo.ldm.dma  If it doesn't show up, it likely
  means that something is blocking the real-time stats messages from
  getting back to our real-time statistics machine, rtstats.unidata.ucar.edu.
  We can worry about this later if needed.

- the change I made was solely as a convenience: I made two links in the
  HOME directory of 'ldm':

  <as 'ldm'>
  cd ~ldm
  ln -s var/data data
  ln -s var/logs logs

  This change is more for us old timers who are used to the LDM logs
  being available in ~ldm/logs, and the data directory structure to
  be accessible in ~ldm/data.

As I end this email, I can report that the LDM appears to be nicely setup on
your machine.  The next step in this process is to figure out what you want
to do with the IDS|DDPLUS products that are now flowing to your machine.

The other thing that you _will_ want to do _soon_ is change the passwords for
the 'ldm' and 'root' accounts on your machine!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: VRK-635010
Department: Support IDD
Priority: Normal
Status: Closed