Confused about ilm, index templates and new indices

[tterranigma]

I have a serve where I install some beats (e.g. packetbeat) but I don't enable the systemd service. I only use packetbeat setup --index-management on this server so that the packetbeat index template and the ILM policy get inserted into elasticsearch. This works fine, I can see the index template and ILM policy in Kibana. These are the settings I use:

setup:
  ilm:
    check_exists: false
    enabled: true
    overwrite: true
    pattern: '{now/d}-000001'
    rollover_alias: packetbeat-%{[agent.version]}
  template:
    enabled: true
    overwrite: true
    pattern: '%{[agent.name]}-%{[agent.version]}-*'
    type: legacy

On a second server, I install packetbeat with the following settings:

setup:
  ilm:
    check_exists: false
    enabled: true
    overwrite: false
    pattern: '{now/d}-000001'
    rollover_alias: packetbeat-%{[agent.version]}
  template:
    enabled: false

On the second server I enable the packetbeat service. I can see logs being sent to elasticsearch. But there are some problems and some questions that I have:

• The index packetbeat creates is packetbeat-7.12.1. This does not match the template pattern that has a dash at the end: packetbeat-7.12.1- and ILM is not enforced neither are the template settings used.
• If I enable the ILM policy, then I can't change the setup.template.pattern in the first server.
• If I set setup.template.enabled: true on the second server, then the index template gets used and ILM is enabled.

However, I cannot understand why I need to set setup.template.enabled: true to the second packetbeat for the whole chain to workk. This setting seems like a setting that is used on beat startup and instructs it whether to push the tempate to elasticsearch or not. At least, this is the case with the setup.ilm.enabled and setup.dashboards.enabled settings. My approach was to disable templating loading on the second server, because the elastic user that packetbeat uses in that installation does not have permissions to manage index templates.

Still, setup.template.enabled seems to affect the name of the index that packetbeat will push to. If this is correct and intended, it should be documented in the packetbeat.reference.yml at least.