The configuration file is encoded in UTF-8 with CR, LF, or CRLF line endings. The syntax somewhat resembles an INI file but is not compatible with an INI file.

• Comment lines (lines beginning with semicolons or pound signs) and blank lines are ignored.
• Lines before the first section are called root-level key/value pairs. Root-level key/value pairs follow a “«key» = «value»” syntax with specific keys.
• Lines in square brackets are called sections. Each section lists a supported service or object (such as a directory, an organizational unit, or an AD group), followed immediately by one or more references to objects that section will examine. Section syntax is described below.
• Lines after a section are called requirements. Requirements describe how things should be. Unmet requirements cause Martinet to email warnings.
• No section has dependencies on other sections. Hence, sections in the same configuration file are unordered.
• No requirement has dependencies on other requirements. Hence, requirements within the same section are unordered. But parts of a requirement on the same line are evaluated together (for example, see the folder section ACE contains requirement).
• There are no line continuations.
• Requirements which require leading or trailing whitespace should be quoted (for example, group name matches " foo "). Not quoting such values risks not properly parsing the significant whitespace.
• Sections which mention multiple references should likely be quoted. References in sections which contain whitespace must be quoted to be properly parsed.
• Each requirement that doesn't describe every matching item in its container (every matching member in a group, every matching object in an OU, every matching subfolder in a folder, etc.) will raise a warning.

• Requirement operators follow patterns depending on the type of the arguments they take:

  Requirement argument type	Requirement operators
  Integer	<, >, =, and != take an integer as an argument. Acceptable integers depend on the requirement but usually do not include negative numbers.
  Strings	matches and not matches each take a regular expression string as an argument. like and not like take a wildcard expression string as an argument. is and is not take a literal string as an argument.

• Some requirements have multiple properties and arguments in semicolon-separated phrases (ACE entry and DNS record requirements, for example). The “«property» «operator» «argument» ;” structure is quite predictable and uses similar operators and arguments to what is listed above. Each phrase is logically ANDed together to identify records or rows of a table which match the given specification.
• Searches through objects that can be nested (such as groups within groups or OUs within OUs) are typically not recursive.

Sections indicate what type of object to look at and what specific objects to look at. For example:

# Martinet will examine the following groups:
# - The group with name "Field Consultants" (identified by its name),
# - The group with canonical name "Field Services OU Admins" (identified by its distinguished name),
# - The groups whose canonical names match the wildcard "Tech Services FC Tech\*" (identified by
#   distinguished name in the canonical name portion). This likely includes the AD group "Tech Services
#   FC TechOps".
# - The AD object with objectGUID 03efc439-b0dc-4615-afed-646fd22dfe34 which is AD group FC-Unix.
[group:"Field Consultants" "CN=Field Services OU Admins,OU=FC Groups,OU=Field Consulting,OU=Delegated,OU=TechServices,OU=Urbana,DC=ad,DC=uillinois,DC=edu" "CN=Tech Services FC Tech\*,OU=FC Groups,OU=Field Consulting,OU=Delegated,OU=TechServices,OU=Urbana,DC=ad,DC=uillinois,DC=edu" "03efc439-b0dc-4615-afed-646fd22dfe34"]

Each section (line 8) starts with an open square bracket, a unique indicator of the section type (such as group), a colon separating the section indicator from the the set of objects to be reviewed, the object references, and a closing square bracket.

The syntax of the text in a section header are section-type dependent. Referenced groups are quoted with double-quote marks on either side of each group reference. Quoting in this manner is needed when a section references multiple objects (multiple local groups, multiple file service paths, multiple certificate references, etc.) for most section types.

Each line is one line even if a line appears to be wrapped here.