fix(arkime): un-shadow db.pl, and make #3346's translation actually run (#3343)

[Xore]

Note on issue state

This issue is already closed (as fixed by #3346), so this PR is a judgement call I would like reviewed rather than assumed: the subject of the issue -- Arkime's own index templates never apply -- is still literally true in the deployed stack, because #3346's translation step never ran. The residual db.pl refusal was also left open in a comment on the issue. Happy to close this if you read the scope differently.

The finding

arkime-init's command: is a YAML > folded block scalar. A folded scalar joins every run of adjacent non-empty lines with a single space. #3346 put the node invocation directly under its comment with no blank line between, so the whole thing rendered as one line:

fi # #3343: translate ... See arkime/composable-templates.js. /opt/arkime/bin/node /opt/arkime/composable-templates.js

The invocation is entirely inside the comment. composable-templates.js had never once run.

Nothing caught it: bash -n accepts the folded line either way, the YAML reads as correct, and there was no test over the rendering. The other 90 lines of that command fold harmlessly (the shell bodies are more indented, so they stay literal).

What this changes

composable-templates.js — a shadow subcommand, run before db.pl and restored after. It deletes every composable template covering an Arkime index family, stashing each body first, so db.pl has nothing to collide with. This is the residual refusal from the issue's comment, implemented as a variant of the option offered there.

Coverage is decided by Elasticsearch's simpleMatch glob semantics, not by name, so a renamed or second catch-all is covered too. Worth noting how the obvious implementation is wrong: testing one invented probe name (arkime_sessions3-shadow-probe) misses arkime_sessions3-2* and arkime_history_v1-?, both of which overlap db.pl's patterns just as hard as a bare *. The matcher asks whether a pattern can match some index of the family.

compose.yml — a bounded three-attempt retry around db.pl. This covers the one race a shadow cannot: a template created while db.pl runs, by elasticsearch-setup's catch-all landing mid-run. It exits non-zero without writing the done marker rather than wedging the deploy, since arkime-capture and arkime-viewer both block on it.

elasticsearch-setup.sh — the false claim removed. The comment asserted the catch-all "explicitly excluded" arkime_sessions3-*/arkime_history_v1-*. Composable templates have no exclusion syntax, so those entries were literal index names matching nothing. The inert entries are gone and the comment names the mechanism that actually works. The 60s wait is kept -- it is the common case and needs no shadow/restore cycle -- but is no longer load-bearing.

Verification

tests/docs/test_3343_fix.py, 22 tests:

• the folded-scalar renderer, cross-checked against PyYAML, asserting the commands survive as commands and that no command line is swallowed by a comment;
• docker compose config-clean, bash -n and shellcheck --severity=error clean;
• the shadow/restore cycle driven end to end against a stub Elasticsearch over HTTP: only Arkime-covering templates are deleted, every other family (dionaea-*, ml-anomalies, ...) survives, stashed bodies come back, the generated templates and the ip-fix fragment are not resurrected, the stash ends empty, and the catch-all is restored even when generate() throws;
• the merge result asserted against the issue's own table: firstPacket date, node keyword, source.ip/destination.ip typed ip, number_of_replicas: 0, and dynamic_templates in the order *Ip, *Tokens, strings_as_keyword -- reversed, every IP is a keyword again.

python -m pytest tests/docs/ -v → 469 passed, 1 xfailed. Against main the same file fails 15 of them, including the headline fold test.

Not done here

• arkime-capture runs db.pl upgradenoprompt --ifneeded after the marker. That is a template update with unchanged patterns, which Elasticsearch only warns about, so it is not the create-path failure above -- but it is not shadowed either, and a future Arkime bump that changes a legacy pattern would surface there.
• Existing indices keep their pre-fix mappings; mappings are not retroactive. Remapping the historical sessions indices is a separate migration, as the issue's closing comment already notes.

Refs #3343

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None