This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Jesse, Thanks for sending this in. RPM support by the LDM package is poor to non-existant (as is support for Ubuntu's, BSD's, and Solaris's package management systems), so I appreciate what others do. > Tom, > > I received your email address from one of our LDM users at SSEC who > usually has us deploy LDM to systems for them. > > We've been distributing LDM onto our systems via puppet using a series > of commands in the module. This is a suboptimal method, so I went ahead > and built LDM RPMs instead and put them on our internal repositories. > > There are a few things that it'd be nice to control and so I thought > it'd be nice to reach out to you and see if you had any insight before i > > went ahead with something in the interest of making it as maintainable > as possible for future admins here: > > (1) the distribution includes <installdirectory>/etc with the source. > Right now, I just use a separate RPM to distribute that initially, then > have new LDM RPMs require it without a version (so that they don't > overwrite it), with the RPM not including etc in its manifest. Interesting solution! I'll have to make a note of it. > In order to activate a new version, I need to replace the runtime > directory (or symlink) via rpm or in a %postinstall scriptlet section. I > can do this method, but I want to first ask you if you feel like I'm > approaching this issue from the correct tack. If an RPM install has the ability to execute arbitrary commands as root, then you should look at the "make root-actions" target in the top-level "Makefile.am". It delegates to scripts in the top-level directory that could also be used by an RPM installation. > (2) LDM wants to write to syslog -- however, we manage our syslog > configurations globally and with our LDM module, we simply create a > rsyslog subdirectory file for it. We'd rather let puppet or rpm > postinstall scripts handle any necessary system configuration such as that. Could your solution for the "etc/" installation be used? I.e., have a separate "/etc/rsyslog.d/ldm.conf" distribution that the LDM distribution would depend on. Do you know if syslog(8) and syslog-ng(8) have this capability? > I don't see any methods for changing that in the configure script. Is > something like that available? We have workarounds in place to make ldm > work fine with rsyslog, but in the interest of transparency and > maintainability we'd like to clean it up. I see that the configure > script searches for the existence of rsyslog and finds it. When the script that modifies "/etc/rsyslog.conf" was created, the system logging daemon didn't have the capability to include configuration files in "/etc/rsyslog.d/" or that capability wasn't widely used. > Best > Jesse Stroik > University of Wisconsin > > > > Regards, Steve Emmerson Ticket Details =================== Ticket ID: YOM-591292 Department: Support LDM Priority: Normal Status: Closed