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

20010427: McIDAS ADDE functionality under RedHat 7.1 Linux

>From:  Gilbert Sebenste <address@hidden>
>Organization:  NIU
>Keywords:  200104280154.f3S1sSL24870 McIDAS ADDE RedHat 7.1 Linux inetd xinetd

Gilbert, et. al.,

I am not writing to jump into the Solaris vs Linux debate (although I
think that Solaris x86 runs much better than Linux, but I run Linux
at home :-), I am writing to make a small comment on McIDAS ADDE
functionality under RedHat 7.1 Linux.

Gilbert noted:

...
>BTW, McIDAS under 7.1 works
>fine, except my ADDE server suddenly stopped working from those people
>trying to get data from me. I think it's back up again...will check.

The problem that Gilbert ran into was caused by the upgrade from RedHat
6.2 Linux to 7.1.  The story is as follows:

o RedHat 6.x Linux runs inetd, and inetd is configured with /etc/inetd.conf

o RedHat 7.x Linux no longer runs inetd.  Instead, it runs xinetd, and
  xinetd uses a different approach to configuration: files in the
  /etc/xinetd.d directory

o RedHat 7.x Linux includes an executable called inetdconvert (a Python
  script) that converts /etc/inetd.conf entries to files in /etc/xinetd.d

o newer versions of Linux (and FreeBSD) include what looks like all
  registered uses of port numbers in /etc/services.  Port 500 (both TCP
  and UDP) is registered to a program called 'isakmp'.

o McIDAS ADDE uses ports 500 and 503 for communications: port 500 for
  uncompressed transfers and port 503 for compressed transfers

All of this sounds reasonably OK until one realizes that there is a
port conflict between McIDAS ADDE uncompressed data transfers and
'isakmp'.  This is easily gotten around by commenting out the 'isakmp'
entries in /etc/services and sending a USR1 signal (not a HUP) to
xinetd.

The problem, however, is that inetdconvert does NOT convert the
/etc/inetd.conf entries for ADDE services (mcserv and mccompress)
correctly.  The /etc/services entries for mcserv (port 500) and
mccompress (port 503) get deleted in the upgrade from RedHat 6.x to
7.x, AND the configuration files created in /etc/xinetd.d for those
services do NOT include the port configuration information that would
obviate the need for an entry in /etc/services.

The solution that returns ADDE functionality is the addition of a port
definition line to the /etc/xinetd.d/mcserv and /etc/xinetd.d/mccompress
files followed by the sending of a USR1 signal to xinetd (which tells
it to reread its configuration files).  After these steps were
performed on Gilbert's machine, ADDE returned to functionality.

I will be updating the Linux section of the Unidata McIDAS
'Notes and Warnings" web page:

http://www.unidata.ucar.edu/packages/mcidas/770/mcx/warnings_mcx.html 

with the steps needed to recover from the RH 6.x to 7.x upgrade later
this weekend.

Tom

>From address@hidden Fri Apr 27 23:30:43 2001
>Subject: Re: 20010427: McIDAS ADDE functionality under RedHat 7.1 Linux 
>From: Jeff Wolfe <address@hidden>

In message <address@hidden>, Tom Yoksas writes:
> 
> o newer versions of Linux (and FreeBSD) include what looks like all
>   registered uses of port numbers in /etc/services.  Port 500 (both TCP
>   and UDP) is registered to a program called 'isakmp'.
> 

isakmp is the Internet Security Association and Key  Management Protocol.

http://www.ietf.org/rfc/rfc2408.txt?number=2408

It's in RFC-2408. It's probably not needed right now, but Windows 2000
and the Active Directory support it, along with a growing number of
firewall and VPN products. It seems likely that there will be
conflicts in the future.

-JEff

>From address@hidden Sat Apr 28 00:38:48 2001

Jeff,

>In message <address@hidden>, Tom Yoksas writes:
>> 
>> o newer versions of Linux (and FreeBSD) include what looks like all
>>   registered uses of port numbers in /etc/services.  Port 500 (both TCP
>>   and UDP) is registered to a program called 'isakmp'.
>> 
>
>isakmp is the Internet Security Association and Key  Management Protocol.
>
>http://www.ietf.org/rfc/rfc2408.txt?number=2408
>
>It's in RFC-2408. It's probably not needed right now, but Windows 2000
>and the Active Directory support it, along with a growing number of
>firewall and VPN products. It seems likely that there will be
>conflicts in the future.

Thanks for updating me on what isakmp is.  I just finished sending off
an email to SSEC (the authors of McIDAS) once again pointing out the
port use conflict, and including your explanation for what isakmp is.

Again, thanks for the information!

Tom