Move to Ubuntu 14.04

[dougburks]

http://blog.securityonion.net/2015/09/bdr2-electric-boogaloo-towards-ubuntu.html

https://groups.google.com/d/topic/security-onion-testing/voIjY2OYjtc/discussion

[petiepooo]

Is this a good forum to discuss some ideas that could be implemented as part of the BDR2?

Ubuntu 12.04 and 14.04 both use upstart to manage startup and shutdown dependencies. I'd long disliked the need for soup as a wrapper for apt-get to handle these dependencies. If one were to convert the apache2 and mysql SysVinit scripts with Upstart scripts instead, and use Upstart for managing all of the NSM components currently managed by the nsm-now scripts, then one could ensure apache2, barnyard2, and sguild were shutdown before mysql was, avoiding the need for that portion of soup. Similarly, if the pfring module were loaded via upstart, one could rely on upstart for shutting down snort-alert (or suricata) and bro as needed too. For details, see http://upstart.ubuntu.com/cookbook/#stop-before-depended-upon-service

I also have dreams of using dpkg-reconfigure instead of sosetup, but that's a whole different ball of wax...

I expect 16.04 to use systemd rather than upstart, but many of the same principals apply, and anything developed for 14.04 to this end should be easily transferred.

[dougburks]

Hi petiepooo,

I think the last time we talked about this we ended up fixing the PF_RING issue and so the only special case remaining is MySQL updates. I'm thinking we might be able to solve that with a dpkg trigger, but haven't done much research yet. Fixing the MySQL case is certainly a whole lot easier and less error-prone than converting all NSM scripts to Upstart.

My overall goal for BDR2 is to change as little as possible so that we can move as quickly as possible and hopefully make the migration as smooth as possible.

[petiepooo]

Hi Doug,

Yes, PF_RING now behaves much better during upgrades. However, I don't believe an upgrade of PF_RING would replace the loaded module without first shutting down the apps that use it, and soup doesn't account for that, meaning a reboot would be required if the user didn't manually stop apps that used it first.

A dpkg trigger may take care of that as well as MySQL dependencies, for any SecurityOnion packages that use it. If any other apps are installed that also use MySQL, they would be out of luck. A generalized solution would give more flexibility for a user adding other apps to a sensor, as I have done.

All that said, there's nothing tying these ideas to the BDR2. They could be developed and rolled out separately on either 12.04 or 14.04. When I get some free time... I wish there were more of it in the day. :)

I concur; keep BDR2 simple and quick.

[dougburks]

Published:
http://blog.securityonion.net/2016/01/security-onion-140431-iso-image-now.html