20010621: McIDAS-X remote ADDE server on Debian Linux (cont.)

>From: "David B. Bukowski" <address@hidden>
>Organization:  COD
>Keywords:  200106202104.f5KL4N116106

Dave,

>The only changes i know of between the redhat and debian upgrades from
>their previous versions is the libc6 change from libc5.  Could libraries
>have changed?

Yes.  My (and other's) thinking is that the change must be in one of three
subsystems:

1) the kernel
2) libc
3) inetd

Regarding 3): RedHat 7.x moved from inetd to xinetd.  The configuration is
different, but the concept is the same.  I have this gut feeling that the
problem is not in inetd/xinetd, but...

>cause libc6 is now glibc2.  Maybe it would have been that
>change over that screwed things up?  any thoughts.  

Yes, it might have something to do with the change.  A conversation yesterday
with Steve Chiswell (our GEMPAK guru) revolved around the possibility of
the meaning of a signal (SIGINT) being changed at some point in the past.
I will be talking to him about this one again today.

>well either the old mcidas box (picard) or  i might be able to swipe
>another dual PPro and do a quick install of linux and ldm and u can handle
>the mcidas stuff we could have a box for u to totally play with and break
>over here too :)

Here is the story:  McIDAS is working fine except for the serving of
sounding data through the remote ADDE server, and even that _usually_
works OK if the client machine is on the same subnet as the server
machine.  Also, McIDAS can access the sounding data with _no_ problems
if the RTPTSRC dataset is found either as LOCAL-DATA or gotten from a
remote machine that is not running a current version of Linux.
Everything else (local and remote access of all other data) seems to
run fine on the latest versions of Linux.

As far as the LDM goes, we have had reports from a couple of sites that
they sometimes see their LDM machine go into a mode of severe disk
thrashing.  This appears to only happen on RedHat 7.1 (I should say
that we only have maybe one or two sites running Debian, and their
machines are not as loaded as the machines that are experiencing the
thrashing).  Have you experienced any of this on weather?  I don't
think so since ADDE access to your box is always very fast.

If you do have a spare box "sitting around" (:-), it would be useful
to run some staged tests to see exactly where things started breaking.
What I have in mind is:

1) I know that RedHat 5.2 (I believe that this is the 2.0 Linux kernel)
   runs all McIDAS code with no problems

2) It would be _very_ useful to start off with an absolutely clean install
   of RedHat 6.0 (or its Debian equivalent) to see if things still worked
   or if it was broken.

3) If RH 6.0 was not broken, I would upgrade to 6.1 and test it, and so on.

4) I know that RH 6.2 is broken (for the remote serving of souning data, of
   course), so the _big_ change had to be somewhere between 5.2 and 6.2.

My suspicion is that the ability to reliably serve sounding data through the
remote ADDE server was lost in the libc upgrade, but I don't know exactly
when this happened.  If it did break then, it seems like it is most likely
that the problem is related to changes in the C library.

What do you think?

re: use of syslog-ng

>basically syslog.conf is overridden by syslog-ng.conf cause thats the
>binary running now... dont really know what happened to syslogd in the
>packages available.  

OK.  This is akin to the movement from inetd to xinetd in RedHat 7.x.

re: we don't know nothing about no stinking syslog-ng.conf ;-)

>If I find out i'll relay the information to you guys/gals :)

Thanks!

>would it be alright to start up a mcidas client running off of cronjob
>batches now at least so we can offload the work of one of the machines
>which i could then prolly set up for u to test off of also... if i free up
>computers i can start using those puters for testing.

Yes, absolutely.  Again, the only thing that does not run 100% correctly
is the remote serving of sounding data.

>I MIGHT have a copy of redhat 6.0 at home somewhere which someone made a
>burn on cd for me of. 

Super.  If you do have a spare box to load it on, and if the box can be
put on the net (and properly safeguarded from hackers!!), then it would
be a useful platform to find out exactly when things broke.

As an aside, we never noticed the breakage at Unidata 'cause we use
Suns for serving ADDE.  Our experience is that Solaris x86 is a much
more robust platform for the applications we support.  If only Sun
would keep up on new hardware like current video cards!

Another aside: one of our site's experience is that FreeBSD is a much
better OS than Linux.  It is faster, less likely to get hacked into,
has better NFS support, and has one of, if not the best TCP/IP stacks
in any OS.  If I could wave a magic wand, I would get more people using
FreeBSD.

>also have slackware on cd at home up to 4.0  3.0 and 4.0 and 3.6 i think
>are the versions i have

I don't know how the Slackware releases translate to the revisions of
libc, etc.  I think that it would be better to stick with looking at
RedHat an Debian for now.

>ps.  if u need to get a hold of me quickly u can email page me at
>address@hidden only 300 characters please else i have to tell
>it to send me MORE of the message like every 250-300 characters which
>takes time :)

OK, thanks.  I will remember this (and make sure that it does not get
into the tracking system!).

>So if u come across an idea u want to test out that would
>work.  And if u want to go conferencing somehow i'm available on icq i can
>fire up and irc, aol/im, yahoo messenger... pretty much any of those.  

OK, sounds good.  Thanks!

Tom