On 10/27/06, Mike Gerdts [EMAIL PROTECTED] wrote:
What if zoneadm monitor -a (all zones) had the ability to spit
syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken,
a subagent to snmpd(1M) would be the right approach.
Speaking as an admin and customer and not a
Mike,
To get it to link, I needed to create a symbolic link at
/usr/lib/libzonecfg.so - libzonecfg.so.1. Time to go searching for
linker options that I haven't needed before... I haven't looked into
it, but for some reason I seem to get some useless events. Consider
the following reboot:
#
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote:
A (large) customer recently asked me to implement a feature whereby they
could monitor zone activity via syslog. The motivation is that for this
customer, any zone state change not during maintenance windows is a cause
for alarm.
I've had a
On Fri 27 Oct 2006 at 09:11PM, Peter Memishian wrote:
So here are my questions:
- Do you think this is useful?
- Do you think the log level (Info) is right? daemon.info is
*not* logged by default, whereas notice is. (So basically: do
you want these
On Fri 27 Oct 2006 at 06:21PM, Dan Price wrote:
Encouraging programmatic use of syslog seems a step in the wrong direction
to me. Surely we can provide a better mechanism to notify them of state
changes?
Such as?
I guess my larger point is that I haven't seen us take steps in the
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote:
As for GPEC, that's what our existing C api is based upon. Take a look at
zonecfg_notify_*() in libzonecfg. It's a real horror show but it does
solve the get the state and then subscribe to future changes and don't
miss anything in between
On Fri, 27 Oct 2006, Mike Gerdts wrote:
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote:
As for GPEC, that's what our existing C api is based upon. Take a look at
zonecfg_notify_*() in libzonecfg. It's a real horror show but it does
solve the get the state and then subscribe to future
