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

20030128: ldm-mcidas upgrade; renegade processes on papagayo (cont.)

>From:  Clint Rowe <address@hidden>
>Organization:  UNL
>Keywords:  200301280007.h0S07h626601 ldm-mcidas LDM 6

Hi Clint,

>I see you've been playin with my ldm, too, not just ldm-mcidas.  I seem to 
>have a very recent version that I know I didn't install ;-)

Yes, we made UNL one of the participants in the testing of the new LDM
6.  I did, however, keep a close eye on data reception on papagayo, so
I don't _think_ that I blew-up anything :-)

>The reason I 
>bring this up is that I read Emmerson's message and checked to see if my 
>ldm was set correctly (I remember setting it to use port 388 a long time 
>and many version ago).  It wasn't and I don't know if that was something 
>you did or if happened when the system was patched.  If it's the latter, 
>I need to tell my computer guy that he needs to check after he installs 

Hmm...  what exactly was not setup correctly on papagayo?  The port 388
issue that Steve brought up is mainly aimed at sites that don't want to
set the SETUID permissions on rpc.ldmd and hupsyslog.  In these cases,
the LDM will still work IF the upstream site is running the
portmapper.  Since the portmapper is one of the areas that is known to
potentially be a security hole, we think that it would be better to not
use the portmapper at all.  Steve made a change yesterday to the order
that the LDM tries to make a connection.  It used to first check the
portmapper and then port 388; now it checks port 388 and then the
portmapper.  This may be all that is done in this version of the LDM.

>Thanks for noticing those processes.  The hpwebjetd was notifying somebody
>of a hung print job).  The print job was mine, but the notice wasn't making 
>it to me for some reason. The other process was something related, but I don't
>know what it was either -- guess I need to check more often.

No worries.  The good news is that E450s have enough muscle (CPUs and
RAM) that this didn't cause any problems.  Without those jobs, however,
papagayo should be idling.

>Anyway, thanks for doing those upgrades for me.

I will continue to upgrade papagayo with new LDM release candidates
unless you tell me not to.  I will also install the "real" LDM 6 when
it is announced.

By the way, you can check on papagayo's data ingestion online at:


Click on stats by host and then papagayo.  There you will see all of
the feeds that papagayo is receiving, and the real time stats plots for
each feed.  The interesting item, however, can be had if you click on
topology (for CONDUIT for example) and then on the machine name from
which you are getting the feed (which is currently thelma).  Wait for a
bit, and you will get a plot of the latency from thelma to papagayo.
This plot is a difference plot of the overally latency at papagayo
minus the overall latence at thelma for the feed you choose.  The point
is that the latencies for CONDUIT at papagayo are essentially
zero/nada/nil.  A good part of the good performance is LDM 6.

>Are you going to Long Beach?

Unfortunately, yes.  I have no enthusiasm for going to AMS this year,
but I will be there nonetheless.  I fly in on Sunday afternoon, and
leave on Thursday afternoon.  If you are going, we need to get together!

Got to run.  We have a person from Internet 2 here talking about use of
the LDM for moving NEXRAD Level II (volume scan) data.  It has been
quite interesting to say the least.  Steve presented stuff on his new
LDM work, and Anne will present stuff on her NNTP work (net news
version of an LDM).  Russ will present his investigations of automated
routing techniques, and Chiz presented his real time stats stuff.

* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*

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.