Antonello Cruz wrote:
On 07/26/10 03:02 AM, John Levon wrote:
On Sun, Jul 25, 2010 at 09:17:00PM -0700, Liane Praza wrote:
To workaround this problem this project will create a new
directory in /etc/logadm.d and an SMF service
svc:/system/logadm-upgrade. A pkg wanting to add entries
in /etc/logadm.conf can drop a file with the entries in that
directory. The start method of the service will look for
logname for the entry, as defined in logadm.conf(4), in
/etc/logadm.conf. If the logname is not found, the entry from
the file will be appended to /etc/logadm.conf. The pkg
dropping
a file in /etc/logadm.d have to set the actuator
refresh_fmri='svc:/system/logadm-upgrade:default' in order to
have the contents of the file processed on install on a live
BE.
How does an uninstall remove the logadm entry? Why can't this just
process /etc/logadm.d in place (like /etc/logrotate.d on Linux) ?
That would be a very reasonable thing to consider when doing
general improvements to logadm.conf (e.g its current re-writing
behaviour which makes it hostile to read-only /etc deployments).
But, it seems like managing the directory in a way that allows
administrative customization like logadm.conf does today would take
more significant interface investment in the Committed parts of
logadm.conf than is an appropriate scope for this project. This
project replaces the S10 i.logadmconf functionality, which did not
support removals either, and was also an ON-private Class Action Script.
We've attempted to set the interface stability at a level which
reflects that.
I'm struggling to understand why it would be difficult, for example, to
treat the default configuration of logadm(1M) as simply the
concatenation of all files in /etc/logadm.d, plus the existing
/etc/logadm.conf for backwards compatibility. Seems like a real nice
KISS solution.
--
Andrew Gabriel
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
