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

20031021: LDM - Redhat Linux 8.0 - ldmadmin start gives permission denied



Anthony,

>Date: Tue, 21 Oct 2003 14:19:46 -0500
>From: "Anthony R Koebele" <address@hidden>
>Organization: USGS
>To: "Anthony R Koebele" <address@hidden>
>Subject: Re: 20031021: LDM - Redhat Linux 8.0 - ldmadmin start gives 
>permission denied

The above message contained the following:

> Since you mentioned the firewall may be an issue it got me thinking. When I
> installed Linux some time ago we did not have a firewall protecting our
> network. Many months ago we implemented a firewall to protect our router.
> After the firewall was in place I changed the setting of the
> redhat-config-securitylevel, however, I never confirmed that the change had
> taken place. I opened redhat-config-securitylevel this afternoon and found
> the setting on high. Interestingly, I can't change the
> redhat-config-securitylevel setting as root. So I ran lokkit. I can now
> send and receive data, but I still have to start ldmadmin as root. The
> redhat-config-securitylevel still indicates it is set at High.

If you must run the ldmadmin script as root, then there is still
something wrong with your system.

> I am still research the firewall issue.
> 
> Thank you.
> 
> Tony
...

> I am the System Administrator so I can become root ...
> 
> Here are the permission denied messages: ldmadmin start as ldm:
> Oct 21 08:28:10 nt14dndbmk syslogd 1.4.1: restart.
> Oct 21 13:28:11 nt14dndbmk rpc.ldmd[3409]: Starting Up (version: 6.0.14; 
> built: Oct 20 2003 15:41:57)
> Oct 21 13:28:17 nt14dndbmk rpc.ldmd[3409]: local_portmapper_running(): 
> clnttcp_create() failure: : RPC: Remote system error - No route to host
> Oct 21 13:28:20 nt14dndbmk pqexpire[3411]: Starting Up

The pqexpire(1) program is deprecated.  It is no longer necessary and
You should not use it.

> Oct 21 13:28:20 nt14dndbmk pqbinstats[3412]: Starting Up (3409)
> Oct 21 13:28:20 nt14dndbmk pqact[3413]: Starting Up
> Oct 21 13:28:20 nt14dndbmk ls1-msr[3414]: Starting Up(6.0.14): 
> ls1-msr.msr.noaa.gov: TS_ZERO TS_ENDT {{PPS,  ".*"}}
> Oct 21 13:28:20 nt14dndbmk ls1-msr[3414]: Desired product class: 
> 20031021132239.593 TS_ENDT {{PPS,  ".*"}}
> Oct 21 13:28:20 nt14dndbmk pqexpire[3411]: > Recycled   7210.611 kb/hr 
> (4101.763 prods per hour)
> Oct 21 13:28:20 nt14dndbmk 204.227.119.162[3415]: Starting Up(6.0.14): 
> 204.227.119.162: TS_ZERO TS_ENDT {{PPS,  ".*"}}
> Oct 21 13:28:20 nt14dndbmk 204.227.119.162[3415]: Desired product class: 
> 20031021132239.593 TS_ENDT {{PPS,  ".*"}}
> Oct 21 13:28:20 nt14dndbmk ls1-msr[3414]: Connected to upstream LDM-6
> Oct 21 13:28:20 nt14dndbmk 204.227.119.162[3415]: Connected to upstream LDM-6
> Oct 21 13:28:20 nt14dndbmk ls1-msr[3414]: Upstream LDM is willing to feed
> Oct 21 13:28:20 nt14dndbmk 204.227.119.162[3415]: Upstream LDM is willing to 
> feed
> Oct 21 13:28:21 nt14dndbmk pqact[3413]: unio_open: 
> data////KFWR-RR5FWR.npt.npt: Permission denied
> Oct 21 13:28:21 nt14dndbmk pqact[3413]: unio_open: 
> data////KFWR-RR3FWR.npt.npt: Permission denied
> Oct 21 13:28:21 nt14dndbmk pqact[3413]: unio_open: 
> data////KFWD-RR3FTW.npt.npt: Permission denied

The "Permission denied" messages above are from a pqact(1) process.
pqact(1) processes are, typically, started by the LDM main
program, bin/rpc.ldmd., as a result of EXEC entries in the LDM
configuration-file, etc/ldmd.conf.

Apparently, the LDM user doesn't have sufficient permission to write to
the output files (e.g., "data////KFWR-RR5FWR.npt.npt").  This could be
because the pathnames are meaningless (too many "/") or because the LDM
user is not in the same user-group as the group that owns the output
files and directories, or because group-write is disabled for those
files and directories.

> Here are the messages: ldmadmin start as root:
...

They look OK.

> Here is the result of cd ~ldm/bin && ls -l rpc.ldmd:
> -rwsr-xr-x    1 root     user       167289 Oct 20 15:43 rpc.ldmd

This looks OK.

> I have been told the firewall rules we have in place between my location ND
> and MN are the same rules in place for another location in ILL. ND to MN
> doesn't have two way communication, however ILL to MN does have two way
> communication. Therefore, it may be my Linux or LDM configuration not the
> firewall rule causing the issue.

The "Permission denied" issue appears to be related to output file and
directory modes and the group to which the LDM user belongs.  You should
be able to fix this easily.

> $  /usr/sbin/rpcinfo -p
>    program vers proto   port
>     100000    2   tcp    111  portmapper
>     100000    2   udp    111  portmapper
>     100024    1   udp  32768  status
>     100024    1   tcp  32768  status
>     391002    2   tcp  32769  sgi_fam
> 
> Thank you.
> 
> Tony

Regards,
Steve Emmerson