feat(images/kuma-init): use iptables-wrapper to use correct iptables version #9701
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…version As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added
ci/run-full-matrix
bartsmykla
requested review from
slonka and
lobkovilya
and removed request for
a team
lahabana
reviewed
Mar 25, 2024
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
…-wrapper-in-kuma-init
michaelbeaumont
approved these changes
Mar 26, 2024
|
backporting to release-2.3 with action |
kumahq bot
pushed a commit
that referenced
this pull request
Mar 26, 2024
…version (#9701) As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot
pushed a commit
that referenced
this pull request
Mar 26, 2024
…version (#9701) As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot
pushed a commit
that referenced
this pull request
Mar 26, 2024
…version (#9701) As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot
pushed a commit
that referenced
this pull request
Mar 26, 2024
…version (#9701) As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
kumahq bot
pushed a commit
that referenced
this pull request
Mar 26, 2024
…version (#9701) As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API. Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.) Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 27, 2024
…ptables version (kumahq#9701)" This reverts commit a33eec8. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 29, 2024
…ptables version (backport of kumahq#9701) (kumahq#9728)" This reverts commit 5711de2. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 29, 2024
…ptables version (backport of kumahq#9701) (kumahq#9724)" This reverts commit 325df19. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 29, 2024
…ptables version (backport of kumahq#9701) (kumahq#9726)" This reverts commit 59b9e60. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 29, 2024
…ptables version (backport of kumahq#9701) (kumahq#9725)" This reverts commit 4da2646. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
to bartsmykla/kuma
that referenced
this pull request
Mar 29, 2024
…ptables version (backport of kumahq#9701) (kumahq#9727)" This reverts commit 78a0ce0. Signed-off-by: Bart Smykla <bartek@smykla.com>
bartsmykla
added a commit
that referenced
this pull request
Mar 29, 2024
bartsmykla
added a commit
that referenced
this pull request
Mar 29, 2024
bartsmykla
added a commit
that referenced
this pull request
Mar 29, 2024
bartsmykla
added a commit
that referenced
this pull request
Mar 29, 2024
bartsmykla
added a commit
that referenced
this pull request
Mar 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As of iptables 1.8, the iptables command line clients come in two different versions/modes: "legacy", which uses the kernel iptables API just like iptables 1.6 and earlier did, and "nft", which translates the iptables command-line API into the kernel nftables API.
Because they connect to two different subsystems in the kernel, you cannot mix and match between them; in particular, if you are adding a new rule that needs to run either before or after some existing rules (such as the system firewall rules), then you need to create your rule with the same iptables mode as the other rules were created with, since otherwise the ordering may not be what you expect. (eg, if you prepend a rule using the nft-based client, it will still run after all rules that were added with the legacy iptables client.)
Checklist prior to review
syscall.Mkfifohave equivalent implementation on the other OSci/labels to run additional/fewer testsUPGRADE.md?