[outreachy] Claiming Bug #2851

[Vidushi Agrawal]

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?

>
>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/outreachy/attachments/20190314/e89814eb/attachment-0001.html>