Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configs/tmpfiles.d: ensure /run/xtables.lock exists #57

Merged
merged 1 commit into from Dec 17, 2021

Conversation

pothos
Copy link
Member

@pothos pothos commented Dec 16, 2021

The nftables update which included using the nftables compat backend
for the iptables binaries instead of xtables on the host resulted in
the lock file not being created anymore automatically. The lock file is
still required because the xtables backend doesn't go away and is used
by containers and, possibly, by invoking the legacy binaries on the
host (we ship them for easy access to the xtables lists).

Use a systemd-tmpfile directive to create the xtables lock file which,
e.g., gets bind-mounted to containers for coordination of xtables
modifications.

How to use

Fixes flatcar/Flatcar#578

Testing done

File got created at bootup in a VM. After file deletion the same file got created again by iptables-legacy -L

  • Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
    ↑ in coreos-overlay

pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Dec 16, 2021
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Dec 16, 2021
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
The nftables update which included using the nftables compat backend
for the iptables binaries instead of xtables on the host resulted in
the lock file not being created anymore automatically. The lock file is
still required because the xtables backend doesn't go away and is used
by containers and, possibly, by invoking the legacy binaries on the
host (we ship them for easy access to the xtables lists).

Use a systemd-tmpfile directive to create the xtables lock file which,
e.g., gets bind-mounted to containers for coordination of xtables
modifications.
@pothos pothos marked this pull request as ready for review December 17, 2021 13:10
@pothos pothos merged commit 5167ee5 into flatcar-master Dec 17, 2021
@pothos pothos deleted the kai/xtables-lock branch December 17, 2021 13:14
pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Dec 17, 2021
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
@dongsupark dongsupark added this to Ready to Release - 2022-01-10 in Flatcar Container Linux Releases Planning Dec 17, 2021
pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Dec 17, 2021
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
pothos added a commit that referenced this pull request Dec 17, 2021
configs/tmpfiles.d: ensure /run/xtables.lock exists
@pothos
Copy link
Member Author

pothos commented Dec 17, 2021

Created a flatcar-3033-backport branch for current Stable

pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Dec 17, 2021
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
t-lo pushed a commit to flatcar/scripts that referenced this pull request Apr 13, 2023
This pulls in flatcar/init#57
to make sure the /run/xtables.lock file exists for coordination of
xtables modifications.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants