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

20030519: using the LDM to request data from an upstream host

>From: "Baek, Steve" <address@hidden>
>Organization: Navy
>Keywords: 200305191923.h4JJN1Ld001623 LDM

Steve,

>I'm trying to connect to an LDM Server located at Salt Lake City with the IP
>Address of 192.133.29.170. For some reason, I can't connect while using
>'ldmping' to verify connectivity.

If the LDM is running on the machine you are trying to feed from, the
connection failure is most likely to be due to one of two things:

- the upstream host does not have an 'allow' line in its ~ldm/etc/ldmd.conf
  file for your machine

- the upstream site has a firewall in place that is not allowing connections
  from your machine/site

>I was wondering if you can tell me how
>exactly connectivity is established between an LDM client and server.

Once the upstream site has an allow line for your machine AND your
machine supports forward and reverse name lookups, then your request to
the upstream machine for a feed(s) will be seen and acted on.  When
data matching the regular expression that you provided for the feed(s)
that want is received at the upstream host, it will be sent down to
you.

>In
>addition, is there a better way to test connectivy other than using ldmping?

Not really.  You can use a 'notifyme' command to see what data
the upstream site is receiving _IF_ that LDM has allowed you to do
so.

>How about testing whether or not the ldm server is functioning correctly?

For the remote machine, ask the admin for the machine if:

- s/he has added an allow line in her/his ~ldm/etc/ldmd.conf file AND
  stopped and restarted her/his LDM so that allow has taken effect

- sees your connection attempts in her/his ~ldm/logs/ldmd.log file;
  if yes and it is being denied, you will find out why

- can do a forward and reverse name lookup for your machine that
  is requesting a feed.  The forward lookup should return back the
  IP address for your fully qualified machine name, and the reverse
  name lookup should return back the same fully qualified host
  name for the IP that was returned from the forward name lookup.

At the same time, you can:

- see if the upstream machine is running an LDM:

rpcinfo -p 192.133.29.170

  This may or may not work depending on if there is a firewall limiting
  your connection.  Also, even if this command shows that an LDM is
  registered, it does not insure that the LDM is, in fact, running.
  One could have been started and then killed off without unregistering
  it.  One thing you can say for sure: if the LDM doesn't show up in
  the listing from rpcinfo, and the access by rpcinfo was not blocked,
  then the LDM is not running on the remote machine.

For the local machine, you could run a 'notifyme -vxl- -o 3600' in one
window as 'ldm' and inject a product into the LDM queue as 'ldm' in
another window.  The notifyme should show that your machine "got" the
product.  This would test your machine's ability to receive get products
into its queue.  See the man page for pqinject for information on injecting a
product into the LDM queue.

I ran the rpcinfo command pointing at your upstream host from a machine
here at the UPC:

/local/ldm% rpcinfo -p 192.133.29.170
   program vers proto   port  service
    100000    2   tcp    111  rpcbind
    100000    2   udp    111  rpcbind
    300029    5   tcp    388  ldmd
    300029    4   tcp    388  ldmd

Since it looks like an LDM is running there, I tried a 'notifyme'
command:

/local/ldm% notifyme -vxl- -o 3600 -h 192.133.29.170
May 19 19:26:35 notifyme[15730]: Starting Up: 192.133.29.170: 
20030519182635.095 TS_ENDT {{ANY,  ".*"}}
May 19 19:26:35 notifyme[15730]: NOTIFYME(192.133.29.170): 7: Access denied by 
remote server
^CMay 19 19:26:37 notifyme[15730]: Interrupt
May 19 19:26:37 notifyme[15730]: exiting

As you can see, I can't list data that the server is getting since it
is denying (not allowing) my access.  The 'Access denied by remote
server' does, however, tell me that I actually contacted that LDM, so
it is running.

>Thanks,

No worries.

Tom Yoksas