Avoid duplicate rules

[shinebayar-g]

Right now program is relying on ufw for duplicate entries handling. Duplicate rules are produced on some scenario like defining allowed ports specifically.

[shinebayar-g]

After #40 program will produce even more duplicate rules on container startup to sync the rules, that's fine. However, I'm not sure I should even consider duplication check for couple of reasons.

1. ufw already handles duplication correctly. This is an idempotent operation.
2. If I have to check duplicate ufw rules, first I have to get the ufw rules, then parse them through to check for duplication, then create ufw rule if it doesn't exist. Or I could probably introduce additional persistent storage like sqlite for O(1) lookup & other information tracking purposes. This path will introduce little bit overhead than simply relying on ufw for handling duplication.

For now, I consider this is not necessary to implement.

[pannal]

So this is entirely normal and can be ignored? When using ufw-docker manually, those duplicates don't get created.

[ 6] 172.18.0.3 443/tcp         ALLOW FWD   Anywhere                   # xxxx:526635d3c7a4
[ 7] 172.18.0.3 80/tcp          ALLOW FWD   Anywhere                   # xxxx:526635d3c7a4
[ 8] 172.18.0.6 32400/tcp       ALLOW FWD   Anywhere                   # yyyy:7ff829f4fb0c
[ 9] 172.18.0.9 443/tcp         ALLOW FWD   Anywhere                   # xxxx:526635d3c7a4
[10] 172.18.0.9 80/tcp          ALLOW FWD   Anywhere                   # xxxx:526635d3c7a4
[11] 172.18.0.7 32400/tcp       ALLOW FWD   Anywhere                   # yyyy:7ff829f4fb0c

[shinebayar-g]

Hi @pannal , In your example your rules are not duplicate, they are all unique. IIRC I was talking about exact duplicate rule check when adding ufw rules. For example, when adding a new rule, ufw-docker-automated doesn't check if that exact ufw rule exists or not, it just adds and leaves duplication check to ufw. I don't quite recall at which event duplication was happening though.

Does your pod have multiple networks? I am curious how you ended up with such rules.

[ 8] 172.18.0.6 32400/tcp       ALLOW FWD   Anywhere                   # yyyy:7ff829f4fb0c
[11] 172.18.0.7 32400/tcp       ALLOW FWD   Anywhere                   # yyyy:7ff829f4fb0c

[pannal]

I've got these:

docker network ls
NETWORK ID     NAME            DRIVER    SCOPE
9e8edc3fc3c0   bridge          bridge    local
85563272b1fc   host            host      local
61de4892a059   none            null      local
eda632a15479   stuff_default   bridge    local

stuff_default being the only one I actively use in docker compose.

The machine itself has only one NIC.

[shinebayar-g]

👍 does your container has multiple IPs?

[pannal]

No it doesn't. What you see there is what came after a reboot of the host machine. The xxxx container had the IP .3 before the reboot and .9 after the reboot.

The second set of forwards were added automatically added to ufw upon reboot.

[shinebayar-g]

Got it. Are you on latest version v0.11.0? If yes and if it's happening I think we should consider it a bug. If you could provide a reliable instructions to reproduce it I can try to fix it.

[pannal]

Well, I've installed it a couple of hours ago, so I'm pretty sure it's the latest one. (4ef0c7306a06b0d04403297c1848608ea8ad8018 /usr/local/bin/ufw-docker-automated)

I've just tried to reproduce it. I did docker-compose down, to take all the containers down (and the "current" correct rules), then deleted the incorrect ones.

After docker-compose up -d the correct rules get created. Once I reboot, the IPs of the containers change, and I get duplicate rules again.

[ikrevem]

@pannal Have you managed to solve this issue? I'm having the exact same problem: when I reboot (or shutdown) the host, the IPs of the containers change and new rules get added without deleting the old ones.

Thanks :)

[pannal]

Unfortunately not, no.