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

[NOAAPORT #FYU-844088]: NOAAport ingest via dish on CentOS 7 issue



Hi Gilbert,

re:
> As you have seen on the LDM-users list, apparently CentOS 7 requires
> you to tell where to direct the output of the NOAAport packets, and you
> then have to tell the LDM where to "listen" for them. Is this a bug,
> a new step that should be documented, or something else?

I believe that it is an indication that multicast routing was not
setup/setup correctly.

Consider what the help for the combined noaaportIngester has to say about the 
'-I' flag:

Usage: noaaportIngester [-n|v|x] [-l log] [-u n] [-m addr] [-q queue] [-b 
npages] [-I ip_addr]
          [-r <1|0>] [-t] [-s channel-name]
where:
     -b npages   Allocate "npages" pages of memory for the internal buffer.
                 Default is 5000 pages. "getconf PAGESIZE" reveals page-size.
     -I ip_addr  Listen for multicast packets on interface "ip_addr".
                 Default is system's default multicast interface.
     -l dest     Log to `dest`. One of: "" (system logging daemon), "-"
                 (standard error), or file `dest`. Default is "-"
     -m addr     Read data from IPv4 dotted-quad multicast address "addr".
                 Default is to read from the standard input stream.
     -n          Log through level NOTE. Report each data-product.
     -q queue    Use "queue" as LDM product-queue. Default is 
"/opt/ldm/data/ramdisk/ldm.pq".
     -u n        Use logging facility local"n". Default is to use the
                 default LDM logging facility, local0. Implies "-l ''".
     -v          Log through level INFO.
     -x          Log through level DEBUG. Too much information.
     -c          Enable Frame Decompression [Default => Disabled ]. 
     -f          Fill blank scanlines for missing Satellite Imagery  [Default 
=> Disabled ]. 
  
  If neither "-n", "-v", nor "-x" is specified, then only levels ERROR
  and WARN are logged.

Notice that the the '-I' flag overrides the default which is to listen to the 
system's
default multicast interface.

re:
> Of note, you do not have to do this with the very latest version of
> Debian Linux.

I think that others are using the NOAAPort ingest component of the LDM
under CentOS/RedHat 7, and we have never seen any comments that would
indicate that users found that they needed to specify the =-I' flag to
get things working (of course, this doesn't necessarily mean that they
didn't; they simply have not sent such comments to us).

Question:

- isn't Allison House running NOAAPort ingest under CentOS 7?

  If yes, can you ask one of their admins if they had to specify
  the '-I' flag?

re:
> Anyway, something needs to be done with this issue, so I am going to
> drive this into both the LDM and NOAAport support ticket system for some
> sort of resolution.

Looking through the online documentation for NOAAPort ingest:

https://www.unidata.ucar.edu/software/ldm/ldm-current/utilities/noaaport/index.htmlhttps://www.unidata.ucar.edu/software/ldm/ldm-current/utilities/noaaport/index.html

I do not see any comments about the need to setup multicast routing, disabling
SELINUX (or putting it into 'permissive' mode), or about making sure that one's
firewall is configured to allow all traffic from the interface to which one's
Novra S300N is connected.  This really needs updating.

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: FYU-844088
Department: Support NOAAPORT
Priority: Normal
Status: Open
===================
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.