NSM: need to handle /etc/init/securityonion.conf properly

[dougburks]

Problem

Traditionally, /etc/init/securityonion.conf is a part of the securityonion-nsmnow-admin-scripts package. Therefore, whenever a new version of the securityonion-nsmnow-admin-scripts package is installed, /etc/init/securityonion.conf is automatically overwritten with the file from the package.

For folks that are testing out Elastic Beta, so-elastic-configure has written a new /etc/init/securityonion.conf. If we deploy a new NSM package and overwrite their elastic securityonion.conf with the traditional version, it will break their system.

Possible Solutions

We have at least 2 options:

1. Build a new /etc/init/securityonion.conf that can handle both pre-elastic and post-elastic conditions.

OR

2. Remove /etc/init/securityonion.conf from install and conditionally install in postinst. If pre-elastic, copy file into place. If post-elastic, do nothing.

[dougburks]

Implemented option 2:
Security-Onion-Solutions/securityonion-nsmnow-admin-scripts@8e39f62

[dougburks]

submitted for testing:
https://groups.google.com/d/topic/security-onion-testing/mMBhKRASWe4/discussion

[dougburks]

published:
http://blog.securityonion.net/2017/11/securityonion-nsmnow-admin-scripts.html