[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LDM #YOM-591292]: Re: [SSEC-TC-req #38956] leogeo.ssec.wisc.edu ldm log file error
- Subject: [LDM #YOM-591292]: Re: [SSEC-TC-req #38956] leogeo.ssec.wisc.edu ldm log file error
- Date: Tue, 06 Oct 2015 13:30:39 -0600
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