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. Antonello
regards john
_______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
