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
