snort [PSARC/2009/256 FastTrack timeout 05/04/2009]

[James Carlson]

Jason Zhao writes:
> Hi, James,
> > James Walker writes:
> >   
> >>     /usr/bin/64/snort                    Uncommitted	64-bit Command
> >>     
> >
> > What's this about?  What does the utility do that actually requires
> > 64-bit operation?  (Does it read from kernel memory directly?)
> >   
>  From functions points of view, there is no difference between 32-bit
> and 64-bit "snort" binaries. 64-bit snort is an optional choice when 
> building
> the binary. And if you really concern about it, I can remove 64-bit
> part. Please tell me your idea.

It's unclear to me why it's needed.  In general, getting 64-bit
versions of plugins sounds like a negative to me, as it forces
producers of those plugins to test twice.  Perhaps more importantly,
when developers choose not to include 64-bit binaries but include
32-bit only (as it's easier to do, and as we've seen with other 64-bit
objects), users will see (over time) that the 32-bit version of snort
is less capable than the 64-bit version.

So, why is it *required*?  Does something about snort work better that
way?  It seems like it shouldn't, and yet this project is forcing more
complexity into the user's hands, and it's unclear why that's a good
answer.

> > Is snort ordinarily used in daemon mode?  If so, shouldn't there be an
> > SMF configuration for it?  Otherwise, users are forced to roll their
> > own, and the project seems incomplete.
> >   
> I finished the SMF manifest in /var/svc/manifest/network/snort.xml;

It looks like the FMRI we were looking for will be:

	svc:/network/snort:default

That seems reasonable to me.  The rest of that material will need to
go through an actual code review.

I note that you're invoking the 32-bit version here.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677