Project

General

Profile

Actions

Documentation #2699

open

document all eve record types and fields

Added by Victor Julien almost 3 years ago. Updated almost 2 years ago.

Status:
Assigned
Priority:
Normal
Target version:
Affected Versions:
Effort:
medium
Difficulty:
Label:

Description

For each document type, document fields and their types. Add examples.

It's probably best to add specific tickets for each of the record types.


Related issues

Related to Task #2685: SuriCon 2018 brainstormNewVictor JulienActions
Related to Documentation #2620: Documentation: tagged_packets / event_type packetNewCommunity TicketActions
Actions #1

Updated by Victor Julien almost 3 years ago

  • Assignee set to Robert Haist
  • Target version set to TBD
Actions #2

Updated by Victor Julien almost 3 years ago

  • Related to Task #2685: SuriCon 2018 brainstorm added
Actions #3

Updated by Victor Julien almost 3 years ago

Actions #4

Updated by Robert Haist almost 3 years ago

  • Effort set to medium

Working on it over at Github: https://github.com/rhaist/suricata-json-schema

Will probably take some time until we have a fully reproducible build but you can expect a preview soon.

Actions #5

Updated by Victor Julien almost 3 years ago

Maybe I'm misunderstanding the purpose of the schema, but the goal of this ticket is to get the userguide updated so that all missing EVE fields are documented.

The JSON schema ticket is #1369

Actions #6

Updated by Jason Ish over 2 years ago

Victor Julien wrote:

Maybe I'm misunderstanding the purpose of the schema, but the goal of this ticket is to get the userguide updated so that all missing EVE fields are documented.

The JSON schema ticket is #1369

I think the 2 are tightly related.

I had started to look at this again, more about how it should look to the end user. I played with using tables in Sphinx, but I don't find that scales well, especially if you want to reformat. When I jumped back to my JSON schema stuff, it is kind of ugly and I'm not sure if it can be used to generate suitable doc for the userguide. So my last attempt is just some custom YAML that I thought I might generate into Sphinx tables. Still not sure if that is a good idea though, given that JSON schema exists.

Ideally there should be one source of truth. If we still feel that JSON schema is suitable for QA testing, maybe that should be it. We could probably do some intermediate processing of it, and perhaps adding extra fields to provide context in end-user doc. By context I mean stuff like: "vlan - only present when the alerting packet has a vlan header".

Actions #7

Updated by Andreas Herz almost 2 years ago

  • Assignee changed from Robert Haist to Sascha Steinbiss
Actions #8

Updated by Andreas Herz almost 2 years ago

  • Tracker changed from Feature to Documentation
Actions

Also available in: Atom PDF