Vault: Systemd Unit file has deprecated features 'Capabilities' and 'StartLimitIntervalSec'

[spuder]

The documentation on this page provides a systemd unit file

https://learn.hashicorp.com/vault/operations/ops-deployment-guide

[Unit]
Description="HashiCorp Vault - A tool for managing secrets"
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/vault.d/vault.hcl

[Service]
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitIntervalSec=60
StartLimitBurst=3
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

If you attempt to use it verbatim on ubuntu 18.04, you will get these errors in journald

Aug 08 10:37:39 foobar systemd[1]: /etc/systemd/system/vault.service:17: Support for option Capabilities= has been removed and it is ignored
Aug 08 10:37:39 foobar systemd[1]: /etc/systemd/system/vault.service:27: Unknown lvalue 'StartLimitIntervalSec' in section 'Service'

uname -a
Linux foobar 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[weakcamel]

I can confirm this bug.

• The one related to StartLimit is easy to fix: the parameter is now called StartLimitInterval as per https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html

• not sure about the Capabilities=. Is anyone aware of the proper solution?

[ncabatoff]

I'm no systemd expert, but on a test system I use

CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
AmbientCapabilities=CAP_IPC_LOCK

like you have, with no Capabilities, and it works fine.

[weakcamel]

@ncabatoff Thank you!
Actually, I've just pruned my vault.service off the legacy Capabilities and the remaining values match those you posted. And, are sufficient to start the service and bind it to port 443.

Phew, I sleep in peace now!

[roooms]

Thanks for raising this issue. I'll take a look at compatibility. The goal is to have it working satisfactorily on Ubuntu 16/18 and Centos 6/7 as we see these distros a lot. It might be that we can tweak these settings and still support all OSes in one file, but with some journald warnings, not errors. If not, we may need to provide different service files depending on the OS.

[roooms]

We are working to merge an updated systemd service file for Vault. We are fixing a configuration issue but not removing deprecated configuration as we continue to support Ubuntu 16/18 and Centos 7 (6 didn't have systemd by default). This means supporting systemd as old as 219.

The result is:

• Leave Capabilities in the [Service] configuration as newer versions of systemd will ignore it (but log lack of support)
• Move StartLimitIntervalSec from the [Service] configuration to the [Unit] configuration for systemd 230+
• Add StartLimitInterval to the [Service] configuration for systemd <230
• Add StartLimitBurst to the [Unit] configuration for systemd 230+ but also leave in the [Service] configuration for systemd <230

[yhyakuna]

Updated the Deployment Guide accordingly.

[roooms]

Based on the above explanation and the updates now live in the Learn portal, I consider this closed. If @spuder or anyone else on this issue has further feedback, please let us know. Thanks!