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

Re: Linux LDM server problem

James,

> To: Unidata Support <address@hidden>
> cc: address@hidden,
> cc: address@hidden,
> cc: address@hidden
> From: "James M. Pelagatti" <address@hidden>
> Subject: Re: 20050701: Linux LDM server problem
> Organization: MIT Lincoln Laboratory, Group 43
> Keywords: 200507012233.j61MXsjo002058

The above message contained the following:

> It's true that we didn't run 'make install_setuids'. But this is
> because we're not allowed to run anything that requires 'root'
> privileges. What we do in these cases is to set everything up that we
> can as normal users then ask a system administrator to perform certain
> specific tasks such as modifying /etc/services or adding a setuid
> privilege.
>
> Now I guess I could ask them to run 'make install_setuids'. But I
> really doubt they'd be excited about running mysterious (to them)
> scripts as 'root' that do who-knows-what to their systems. So I first
> tried to follow what 'make install_setuids' actually does through
> the chain of Make files. From what I can tell, it seems to boil down
> to simply setting the owner of 'rpc.ldmd' to 'root' and its mode to
> 4755, then a file comparison is done, then full execute privileges are
> added, and finally the file is moved into the proper 'bin' directory.

Conceptually, the file is first copied to the destination "bin/"
directory and then the ownership and setuid bit are set.  In the
"src/server/" directory, the file "rpc.ldmd" should still be owned by
the LDM user and the setuid bit should be unset.  This is just for your
information, however, as the issue is largely irrelevant.

> This is then repeated for hupsyslog. But note these excerpts from my 
> original message:
> 
> >>tornado:
> 
> >>  [ciws]tornado:/ldm/etc 40 % ls -las 
> >> /ll/ciws/projects/ldm/bin/Linux/rpc.ldm
> >>d
> >>   168 -rwsrwxr-x    1 root     ciws       158643 Nov 22  2004 
> >>/ll/ciws/projects/ldm/bin/Linux/rpc.ldmd*
> 
> >>whirl:
> 
> >>  [ciws]whirl:/ldm/etc 85 % ls -las /ll/ciws/projects/ldm/bin/SunOS/rpc.ldmd
> >>   352 -rwsrwxr-x   1 root     ciws      171768 Nov 18  2004 
> >>/ll/ciws/projects/ldm/bin/SunOS/rpc.ldmd*
> 
> >>typhoon:
> 
> >>  [ciws]typhoon:/ldm/etc 122 % ls -las 
> >> /ll/ciws/projects/ldm/bin/Linux/rpc.ld
> >>md
> >>   168 -rwsrwxr-x    1 root     ciws       158643 Nov 22  2004 
> >>/ll/ciws/projects/ldm/bin/Linux/rpc.ldmd*
> 
> Are not these already the correct settings for rpc.ldmd?

Those are, indeed, the correct settings for the installed LDM program,
"rpc.ldmd".

> And though our copies 
> of hupsyslog do not have the correct settings, isn't it true that this only 
> affects logging not network connection issues?

That is correct.

> In addition, given that the rpc.ldmd settings are the same on the
> server that works (whirl) and the one that doesn't (tornado), doesn't
> that suggest that this isn't an issue?
>
> If you insist that this is the likely solution, then I'll ask the
> administrators to run this 'make' for me but I'd like more information
> before I do so.

There's another possibility.  Linux can be told not to honor the setuid
bit.  Use the mount(1) command on the installed "bin/" directory and see
if one of the attributes is "nosetuid".

The LDM logfile entries you previously sent contained the following:

    Jul 01 19:44:26 129.55.60.9[2223]: Starting Up(6.1.0): 129.55.60.9: TS_ZERO 
TS_ENDT {{NEXRAD2,  "^L2.*KPUX"}}
    Jul 01 19:44:26 129.55.60.17[2222]: Desired product class: 
20050701192926.919 TS_ENDT {{NEXRAD2,  "^L2.*KPUX"}}
    Jul 01 19:44:26 129.55.60.17[2222]: INFO: ldm_clnt.c:226: Couldn't connect 
to LDM 6 on 129.55.60.17 using port 388; ldm_clnt.c:113: : RPC: Remote system 
error - Connection refused
    Jul 01 19:44:26 129.55.60.17[2222]: INFO: ldm_clnt.c:245: Couldn't connect 
to LDM 6 on 129.55.60.17 using portmapper; ldm_clnt.c:113: : RPC: Remote system 
error - Connection refused
    Jul 01 19:44:26 129.55.60.17[2222]: ERROR: requester6.c:455; 
ldm_clnt.c:256: Couldn't connect to LDM 6 on 129.55.60.17

The format of the above entries is unusual in that the messages only
contain a single host identifier and no program name.

It appears from the above that the operating system on host 129.55.60.17
is not allowing connections to either port 388 (the LDM) or port 111
(the portmapper).

You should test this from another system by executing commands like the
following:

    rpcinfo -p 129.55.60.17
    rpcinfo -n 388 -t 129.55.60.17 300029 6

Please let me know what you discover.

> ---------------------------+---------------------------
> James M. Pelagatti (Jamie) | MIT Lincoln Laboratory
>    Software Engineer        | Group 43 (Weather Sensing)
>    (781) 981-1886           | 244 Wood St., Room S1-611
>    FAX: (781) 981-0632      | Lexington, MA 02420-9108
>    mailto:address@hidden  | http://www.ll.mit.edu

Regards,
Steve Emmerson

> 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.