Hi James & Michael Thanks for your feedback.
*About the issue tracker:* As said, I'm more in the web dev industry and just see how thing go there - but it's totally acceptable if I'm the only one sharing this thought. Since both of you are more likely better "stereotypes" of the typical OSSEC user I'd say that I might have been wrong. Still, it might be of value to see that other opinions exist as well :) *About the log file name:* I've expected that. How do you usually solve that problem (beside not using software with that crappy logs)? *About the reports:* * * Didn't know this tool. Looks great and easy to create some kind of wrapper/automation around it. So the question is if either it'd be useful for a large user base or not to have some kind of configuration for it in the ossec conf. Personally I'd like it...and we should always ask ourself if adding a feature could add such a benefit that more users'd use OSSEC. as of course it's also legitimate to not include features to not blow up things. I'm pretty sure to new to the community to answer such questions. :) Thanks Michel Am Freitag, 20. September 2013 12:20:14 UTC+2 schrieb Michel Käser: > > Hi all > > Saving time by not telling you how amazing OSSEC is, I'd like to get > straight to the point and suggest some features/improvements for OSSEC. > > It might be that some of those were already discussed earlier, some of > them might already be implemented (and I just don't know about them) or > whatever - please excuse those cases. > > Suggestions > ----------- > > 1. Daily/weekly/monthly reports > > Beside the live alerts, it'd be great to have a configuration option for > mentioned reports. > > Example: Allow to send a weekly report/summary of alerts with level X or > higher to address xy. > > Well-knowing that most alerts with a level X should be managed > right-away, it'd still be great to have this option. Either for > reflection, just as a summary or people that don't need the live alerts > can still get a summary of what happened within the given time frame > (e.g. your boss want's that or so..) > > 2. Log file name/location for decoder > > I'm not very sure if this is really needed. I however have some very > generic log files that don't contain any app/system name etc. - just the > plain information. > > Having a lot of these logs may/can lead to decoder problems (e.g. the > decoder has to be very generic too and it will become hard to write ones > that still extract the right information. > > Example: In decoder definition, allow > <log_file>/var/log/auth.log</log_file> so the decoder only is activated > if the message is from given log file. > > 3. Per distro configuration > > OS is already supported and per distro can easily be done using > profiles. Still, I'd like that > > 4. A public issue tracker > > As "jrossi" mentioned on IRC (if I interpreted right) he's thinking > about how to grow the OSSEC (developer) community. Well - personally I > guess a public issue tracker could help. > > Mailing lists are awesome, I love them. But...I think a lot of people > are still not very familiar with those. I might be totally wrong (I'mmainly > doing stuff in web development/frontend etc. which is a different > world..somehow more "up-to-date" and focusing on new technologies > (letting open if that's good or not), but still...I think a real > issue/feature tracker could help. > > There's a lot of great software out there, so this could be archived > relatively easily. > > Main points why: > - mailing lists may deterrent people > - mailing lists require more initial work (signing up) where a real > issue tracker just allows you to post (or at least register the "usual" > way) - which I think will lead to more submissions > - people don't know if a mailing list is the right place for feature > requests/bug reports etc. (some here..I asked on IRC) > - and actually I'd like to mention an example (I know this is idiotic > and most time you cannot say that things that work for project X do the > same for project Y, but..). I'm somehow active within the ISPConfig > project (it's an open source control panel à la cPanel). It has a forum, > a website, an IRC channel etc. My personal experience is, that the issue > tracker is used very active. Not only by people how are active anyway, > but also by people how just report one bug or something like that. Now - > ask yourself. If you find a little bug in a program/system you're using > (and you could live with it (e.g. if it's not getting fixed)) - would > you prefer subscribing to the mailing list and writing a long mail there > or just posting a little ticket at a public issue tracker.... you see. > > I'm totally open for critic and comments and will not become angry if > nothing of these will become reality (of course not) - however, I wanted > to suggest them. > > Thanks, > Michel > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
