Hello from Greg Harewood

[gregharewood]

Hi All!

I'm a little embarrassed to be introducing myself here... having being doing this stuff since 1994. ish. (fw1 3.0b was my first customer install.) But working at Nokia, I tended to have all the resources I needed internally, and didn't seek out the community stuff. It's like coming out from a darkened room and finding that there is a beautiful world beyond your own little hide away!

Firstly, if I ever trained any of you - please please say HI! I was Nokia's EMEA security training manager from 1999, did Professional Services from 2002 to 2004, and then ran the security portfolio globally til 2007.

Secondly - is there anyone else here interested in IPSO package development? There's not much going on with binary development for IPSO because you need Nokia's permission to use the SDK, but you can do an awful lot with TCL, HTML and Perl on the platform.

Finally - Please help me out when I ask stupid questions about SPLAT, non-IPSO upgrade concepts, non-IPSO clustering, and all the other things that I had the luxury of ignoring for years :).

Great to meet you all!

Kind regards,
Greg Harewood - gregharewood at ipsilonconsulting co uk
Ipsilon Consulting Ltd, UK.

[melipla]

Hi Greg--glad you've found your way to the forum! Its a great place to share information and help out. I'm sure you'll have a good time correcting all my IPSO-misinformation that I inadvertently share. ;)

What kind of packaging can you do with IPSO? I wish SPLAT had something similiar....

[gregharewood]

Thanks for the note :)

Originally Posted by melipla

What kind of packaging can you do with IPSO? I wish SPLAT had something similiar....

An IPSO package is a tgz file unpacked under /opt. It contains a /opt/packagename/MANIFEST in a very simple format. In fact you can develop a package in place - Voyager will list it for enabling if it sees the MANIFEST file, and scans dynamically whenever you go to the manage package page. Unlike an rpm on SPLAT, you must home the package under /opt. But you can run scripts on various events (START, STOP, INSTALL) if you must copy stuff to places outside of /opt.

Easy mechanisms are provided for writing voyager pages (templates, or tcl scripts) and working with the config system. With templates, pseudo html tags link fields direct to database fields. Make a page describing what you want to configure, and write a shell script to read the database entries and implement your functionality.

You can see immediately that you could write scripts to implement repetitive stuff, check that configs comply with expectations, return measurements to logging systems, adjust cluster or vrrp priorities at regular intervals if subsystems are faulty, adjust Check Point dynamic objects or user mappings and so on.

Nokia was never sure what they wanted to support in regard to 3rd party packages. All the technology is there but I sometimes wonder if the powers that be there really understand what's great about IPSO and why people buy it. With the phases they've been through of not exactly always having the fastest FW1 boxes or the best bang for the buck, you'd think that letting 3rd parties make IPSO great for them would be a win. But they've tended to be reticent about letting the C compiler out, or approving 3rd party code for sale. But nothing stops it being done for consultancy.