[root@primary ~]# /etc/init.d/ossec-hids restart
Shutting down ossec-hids: [ OK ]
Starting ossec-hids: 2011/04/08 10:00:20 ossec-testrule: INFO: Reading decoder file etc/decoder.xml.
2011/04/08 10:00:20 ossec-testrule: INFO: Reading decoder file etc/decoders.d/01-asl-decoder.xml.
2011/04/08 10:00:20 ossec-testrule: INFO: Reading decoder file etc/decoders.d/decoder.xml.
2011/04/08 10:00:20 ossec-analysisd(2102): ERROR: Duplicated decoder with prematch: 'pam-user'.
2011/04/08 10:00:20 ossec-analysisd(2105): ERROR: Error loading decoder options.
2011/04/08 10:00:20 ossec-analysisd(2106): ERROR: Error adding decoder plugin.
2011/04/08 10:00:20 ossec-testrule(1202): ERROR: Configuration error at 'etc/decoders.d/decoder.xml'. Exiting.
2011/04/08 10:00:23 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/08 10:00:23 ossec-rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/08 10:00:31 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/08 10:00:31 ossec-rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/08 10:00:44 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/08 10:00:44 ossec-rootcheck(1211): ERROR: Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
[FAILED]

Can the rules be fixed please?

There are a bunch of sick rules killing it

/var/ossec/etc/decoders.d/
01-asl-decoder.xml
decoder.xml

and

/var/ossec/etc
decoder.xml

Thank goodness I had a working decoder.xml on another server. The sick one has file size of 88116
Please update the rules ASAP

This is a bug in the beta, not actually in the rules (ASL 2.2 does not have this issue). An update in ASL 3.0 Beta will be needed for this.

I am running asl-testing. Just updated to 2.9.0-0.43 and its STILL broken.

[root@server ~]# /etc/init.d/ossec-hids restart
Shutting down ossec-hids: [ OK ]
Starting ossec-hids: 2011/04/09 16:03:02 ossec-testrule: INFO: Reading decoder file etc/decoder.xml.
2011/04/09 16:03:02 ossec-testrule: INFO: Reading decoder file etc/decoders.d/01-asl-decoder.xml.
2011/04/09 16:03:02 ossec-testrule: INFO: Reading decoder file etc/decoders.d/decoder.xml.
2011/04/09 16:03:02 ossec-analysisd(2102): ERROR: Duplicated decoder with prematch: 'pam-user'.
2011/04/09 16:03:02 ossec-analysisd(2105): ERROR: Error loading decoder options.
2011/04/09 16:03:02 ossec-analysisd(2106): ERROR: Error adding decoder plugin.
2011/04/09 16:03:02 ossec-testrule(1202): ERROR: Configuration error at 'etc/decoders.d/decoder.xml'. Exiting.
2011/04/09 16:03:05 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/09 16:03:05 ossec-rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/09 16:03:13 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/09 16:03:13 ossec-rootcheck(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/09 16:03:26 ossec-syscheckd(1210): ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2011/04/09 16:03:26 ossec-rootcheck(1211): ERROR: Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
[FAILED]


Something is wrong with the OSSEC rules. Only the old decoder.xml works and you have to disable all the rules in /etc/decoders.d

I did file this as a bug, but it was closed as rejected without a single explanation, just closed as rejected.

Seems bugs are not being tracked in testing and therefore its going to take forever to fix things as you have no feedback on what is happening.

I think you misunderstood me, this is a bug that only effects the 3.0 beta and its not caused by the rules (more on that in a moment).



While I'm not sure why you would expect a bug in a testing build to be fixed in less than 36 hours, we do appreciate your enthusiasm to get this issue resolved. Rest assured the issue was already known and will be addressed in due course along with other priorities as we continue to develop ASL 3.0.

Let me take this moment to reaffirm that our test builds are previews. They are not meant to be run on production systems nor should one expect them to be bug free: test builds may have bugs, they may ruin your credit and give you bad acne. If you have a production system, you should use the stable build of ASL and not a testing build. Test builds are not supported for this reason: They are test builds, not production builds.

We realize you may want to have the next version of ASL as soon as possible, and we appreciate your enthusiasm as well as taking the time to try out test builds. We expect to release the final version of 3.0 this quarter and we will resolve this bug as soon as possible in an upcoming test build release.

As as aside, although it looks like the decoder is the cause of the problem, its actually not. Although it appears the default decoder will resolve this for you, and although it loads, the problem is actually in OSSEC itself and the default decoder is actually going to cause other issues for you. Rest assured that your first report in the forums was already being addressed, so there is no need to keep reporting the same bug. We address every bug reported and continual reports of the same bug are not necessary. We know what the actual cause is, and it is being addressed in due course.

So for anyone not running a testing build, this bug does not in any way effect 2.2.

As always we appreciate the bug report and will continue to work hard to make sure that our stable builds are bug free. When ASL 3.0 is production ready we'll be sure to let you know, and thank you again for the report.

Hi Mike,

No you missed my point. I don't expect a test bug fixed over the weekend. But if I put in a bug, I expect some feedback than slamming the door in my face with 'rejected' without a single comment.

What feedback do I have someone even cares there is a bug.

In fedora for example testing builds there are bugs opened in bugzilla they get addressed.

Without feedback how do you know it's a known bug already or it's addressed or even will be.

It's not the issue of expecting a testing package to work flawlessly, but some feedback and updates to issues need to be addressed, else no one will run testing, bugs don't get found out, so in that case why bother having testing channel at all it becomes a black hole lucky dip.

Why not make this forum private and address the known bugs here. Testers can comment or add there own and some progress happens.

It's like my bug about the missing asl graphic in asl-web sure it's not urgent, but how many builds and no one can be bothered either adding it into the source, or clean up the yum update so a simple update of asl-web can happen without having to manually remove the old package as it won't remove with the update due to the missing graphic. It's been months.

The single one and only response I got about that was here in another thread. How hard is it to leave the bug open and comment, rather than close it as 'rejected' without a single word.

It's not even the case of customer support, more the case of manners and some caring for someone bothering to try the code and help.

Cheers,
David

So I believe you may have misunderstood the right way to report a bug. I just looked at your account and I do not see any bug reports from you on this issue (please let me know if the system is in error), so I opened a bug report for you(#553). I also dont see a bug report opened by you for the missing graphic, so I added that one as well. (#554)

First of all let me apologize if you did not understand the correct procedure for filing a bug report for testing builds (unsupported software). You opened a case, and cases are used for support requests for supported software. So, the support team rejected the request because it was not for supported software. Bug reports are used to report bugs, be it in supported or unsupported software. And you opened a case, so it was rejected.

With that out of the way, let me explain the support process. Cases are for supported software, testing builds are not supported so the standard procedure for unsupported software was to reject the request for support. I've changed the process in case someone opens a case in the future for unsupported software. If that occurs, the support team will now close the case as a defect (for cases like this, if the request is for support with something we dont support, like mysql, the case will be rejected). The support team will do that as a low priority because its unsupported, it takes time away from actual support request and they will get around to that as other priorities allow. If you open a case for testing builds, please dont be surprised if it takes a few days to create that bug report for you.

The fast way to report a bug is to open a bug report. Its direct, immediate (we dont have to create a bug report for you) and it goes straight to the dev team so they can start working on it now. This cuts out a lot of steps in the workflow which helps us to reduce time to get these bugs fixed. So fixes will come out faster.

So just remember, Cases go to the tiered support team, that handles everything from billing issues, usage questions, installation issues, etc. That process is much slower because we triage, and unsupported software goes to the bottom of the list.

Bug reports go straight to the development team.

So please, if you have a bug, open a bug report, not a case. And I apologize if the process was not clear, please open bug reports for bug, not cases. If open a case in error, we will eventually open that bug report for you manually. Please be patient as creating a bug report for you for a testing builds will be a low priority. If you want faster attention, just open a bug report.

And if you do have an issue with supported software, please open a case.

Also, I'm not sure why replying to the thread you created was not adequate feedback for you, but we'll do our best to keep trying to communicate. We like open forums because that way everyone can discuss these issues. The bug tracker is private, so if you have a private issue, please use that.

Thank you again for reporting this bug.

I think there has been a simple misunderstanding, is all.

"Cases" and "bugs" in the support portal don't have self-evident functions in terms of use both for current but only bugs for devel.

Maybe some suitable text in the support portal welcome screen would be a good idea?

I'm sure there's info in the Wiki, but like I've said in the past, I often find it very difficulty to locate what I need in there. I have no idea why other than the possibility of me suffering from Wikilexia.

Great idea, we'll noodle on this about the best way to direct things.



I think the search engine in wikipedia is a little weak personally. Its been on the todo list for awhile to investigate other options (we tried out google search too, but its a little too broad surprisingly...). How is the search engine in the support portal by comparison? If it seems more workable we could work to duplicate the content there so at least you have a few different tools to use for searching in the interim.