In r15138 I added a new 'phonelogd' service - it is a separate instance
of syslogd that is configured to accept remote clients (no filtering)
and write everything to .../var/log/sipxpbx/phonelog/phones.log (which
is included in snapshots). 

The service is not managed by sipXsupervisor (so that it can run when
sipXecs is not running) - it is started from init.d as sipxecs is, but
it requires a configuration file .../etc/sipxpbx/phonelog-config with
one configuration item: 

PHONELOG_ENABLED : TRUE 

(if the file is missing or the value of the above is not 'TRUE', then
the service is disabled). 

At this point, no default configuration file is installed (in keeping
with the new-and-improved philosophy). For now, the configuration file
is declared by the sipxconfig-process.xml file so that it can be written
using the sipXsupervisor replication mechanisms. 

A source build does not activate the phonelogd service, but an rpm
install does (but read on).

To enable the service, the configuration file must be written and then
the system level service must be (re)started (or, if the service was
enabled previously, the system rebooted). 

So... the question is - do we really want to _also_ add something to the
setup wizard to ask the user whether or not to write that configuration
file?

Pros:
      * No reboot or shell command needed to activate the phone logging.

Cons:
      * If we write the file in the setup, then sipXconfig has to read
        it to figure out the state.

I would prefer _not_ to enable this from setup.  This is one-time thing,
most likely.

Note also - it's not a completely safe thing to allow phones to log this
way.  It creates an opportunity for an attacker to fill your disk with
bogus log entries.  Some newer versions of syslogd have some protections
against this (but no such protection can be complete or infallible) -
unfortunately the CentOS5 syslogd does not.



_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to