[IDD #VJN-743814]: GEMPAK

Hi Massoud,

re: 
> I didn't rebuild the LDM after June 27, however, the
> permissions on hupsyslog changed yesterday for testing
> purposes. As <root>, I changed the permissions for
> hupsyslog, syslogd.pid, and syslog.conf, so I wouldn't
> receive the following message anymore as <'ldm'>.
> 
> [ldm@wimden logs]$ hupsyslog
> hupsyslog: couldn't open /var/run/syslogd.pid

The 'sudo make install_setuids' step in the LDM installation
process is there to set the correct permissions on both
hupsyslog and rpc.ldmd.  This procedure should not be changed
_unless_ one is an expert Unix user.

> Apparently, this only worked when I tried using 'sudo
> hupsyslog' or 'sudo ldmadmin pqactHUP' because the
> appropiate files are being read from <'root'>.

Again, 'sudo make install_setuids' sets the ownership and
run permissions for hupsyslog and rpc.ldmd so that they
will run with 'root' privilege. This should be equivalent to
your running 'sudo hupsyslog'.  If it is not, it means that
your system administration staff has changed something on your
machine that does not allow these programs to be run with
setuid root privilege.  This can happen, for instance, if the
executables are located on an NFS-mounted file system which
has had setuid root privilege blocked.  If this is the case
on your system, I suggest moving the HOME directory of your
'ldm' user to a file system that is local to your machine.

> On Monday,
> I'll go ahead and set the permissions on hupsyslog
> correctly based on your suggestions this morning. When I
> have completed the necessary steps, I'll email you the
> results again of ls -alt `which hupsyslog.'

Very good.

> I'll also send
> you the list of files from my ~ldm/bin directory and any
> other problems I run into with hupsyslog.

If after running the 'sudo make install_setuids's step your
hupsyslog still is unable to read the process id for syslogd
stored in /var/run/syslogd.pid, you should start working with
your system administration staff to remove whatever they have
implemented to block the correct implementation.  If they
are worried about security issues, please have them contact
us so we can reassure them.  Also, they can always read the
source code for hupsyslog and rpc.ldmd to verify that there
are no security issues.

> By the way, do you know if Steve Chiswall has been around
> this week because I haven't received any responses to my
> GEMPAK emails over the past three days?

We are all busy preparing new distributions of the packages we
support for release before our upcoming series of training
workshops.  In addition, we are supporting at least 160 different
institutions in their use of our software.  Steve has been heavily
overburdened by support inquiries this summer while he is trying
to prepare his new GEMPAK release and get ready for his GEMPAK
training workshop.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: VJN-743814
Department: Support IDD
Priority: Normal
Status: Closed