snort [PSARC/2009/256 FastTrack timeout 05/04/2009]
Jason Zhao
Jason.Zhao at sun.com
Mon May 4 22:07:26 PDT 2009
Hi, James,
> 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.
>
The developers of snort community suggested me that 64bit is
only optional. From function points of view, it will be OK as long
as the snort binary has been built same with plugins. Output data
types, such as unified2 and database, are logging pieces of data,
not specific data structures, so the utilities that read those don't
have to be built 64bit.
OK, I will remove the 64bit binaries and its related plugins. Then
I will send for code review first.
>
>>> 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
>
Yes, correct FMRI.
> That seems reasonable to me. The rest of that material will need to
> go through an actual code review.
>
I will send it for code review ASAP.
> I note that you're invoking the 32-bit version here.
>
>
Yes, of course.
Thank you very much!
Jason
More information about the opensolaris-arc
mailing list