[outreachy] Claiming Bug #2851
Shivani Bhardwaj
sbhardwaj at openinfosecfoundation.org
Thu Mar 14 05:34:59 UTC 2019
On Thu, Mar 14, 2019 at 12:42 AM Vidushi Agrawal <vidushi229 at gmail.com> wrote:
>
>
>
> On Wed, Mar 13, 2019 at 11:46 PM Shivani Bhardwaj <sbhardwaj at openinfosecfoundation.org> wrote:
>>
>> On Wed, Mar 13, 2019 at 4:18 PM Vidushi Agrawal <vidushi229 at gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 13, 2019 at 2:05 PM Shivani Bhardwaj <sbhardwaj at openinfosecfoundation.org> wrote:
>> >>
>> >> Hi, Vidushi!
>> >>
>> >> On Wed, Mar 13, 2019 at 1:28 AM Vidushi Agrawal via Outreachy
>> >> <outreachy at lists.openinfosecfoundation.org> wrote:
>> >> >
>> >> > Hi,
>> >> > I'd like to start working on Bug #2851. If none's assigned to it yet, can it be assigned to me?
>> >> Yes, please. Go ahead and start working on it. Do you mind making an
>> >> account on redmine? I shall assign the task on tracker to you.
>> >
>> > I've made an account on redmine.
>> >
>> >> > Also, could you please guide me how to reproduce the issue after changing update.yaml file?
>> >> All the explanation is assuming that you have a working installation
>> >> of suricata-update.
>> >
>> > Yes, now I do have a working installation of suricata-update.
>> >
>> >> See below.
>> >> One good thing to do would be to use "-v" flag while running
>> >> suricata-update. You'll get to know about a lot of settings and
>> >> environment like where the different cofiguration and rule files
>> >> reside which suricata-update is trying to read/write from/to.
>> >>
>> >> For this particular issue, in the log after running "./bin/suricata-update -v",
>> >> Look for "Loading /path/to/update.yaml"
>> >
>> >
>> > On running "./bin/suricata-update -v", I get the loading message
>> > 13/3/2019 -- 15:54:13 - <Info> -- Loading /usr/local/etc/suricata/suricata.yaml
>> >
>> > There's "Loading /path/to/suricata.yaml" not update.yaml
>> >
>> Could you please create one in /etc/suricata? See sample update.yaml
>> here: https://suricata-update.readthedocs.io/en/latest/update.html#example-configuration-file-etc-suricata-update-yaml
>
>
> I created one update.yaml in /etc/suricata and I checked the path in config.py. It still loads suricata.yaml instead of update.yaml. What could the possible fix be?
Could you please give the entire log?
>>
>>
>>
>> >> Then make the changes as described by the person (in the issue on
>> >> redmine) in update.yaml file on the path you just discovered from the
>> >> above mentioned log line.
>> >> On looking closely at the log, you will see a line "Parsing
>> >> rules/emerging-deleted.rules."
>> >
>> > Yes, I do see this line.
>> >
>> >> This is the problem that the person is defining. Despite defining in
>> >> the configuration for update to ignore any rule files with
>> >> "deleted.rules" in their name, a file with name *deleted.rules is
>> >> still being processed.
>> >
>> > I did understand the problem. But on running suricata-update with -v flag, it is loading suricata.yaml not update.yaml. Am I doing it wrong or is it a problem with the installation?
>> >
>> >> Now, apply the changes you think are ideal for this case. Run
>> >> suricata-update again with -v flag. Observe the output. The "Parsing
>> >> rules/emerging-deleted.rules." should no longer be in the log.
>> >>
>> >> You could store the logs in both the cases and then run a diff on them
>> >> to see if something changed as per your expectations.
>> >> Does this help?
>> >
>> > Thank you
>> >>
>> >> > Thanks,
>> >> > Vidushi
>> >> > _______________________________________________
>> >> > Outreachy mailing list
>> >> > Outreachy at lists.openinfosecfoundation.org
>> >> > https://lists.openinfosecfoundation.org/listinfo/outreachy
>> >>
>> >>
>> >>
>> >> --
>> >> Shivani
>>
>>
>>
>> --
>> Shivani
--
Shivani
More information about the Outreachy
mailing list