-
-
Notifications
You must be signed in to change notification settings - Fork 59
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
[unmanaged] Handling of unmanaged sections modifies the order of sections #64
Comments
#65 is merged, now we should remember to change the default |
Now that #67 is done, I was thinking to close this but maybe we leave it open because the issue is not really resolved? We just worked around it by disabling it since it's probably not used very much. But if someone uses it on configuration that need to maintain their order they'll incur in this issue. |
👍 |
@okraits I think the index can be stored and sections can be re-inserted in the same place, but there's no advantage for us in doing this now since we don't use this feature |
Yes, indexes need to be stored in any case. I guess there could be scenarios where the configuration update modifies the order of sections (or creates new sections) so that a collision happens between the indexes of the unmanaged sections and the indexes of the rest of the configuration. But we need to look into that anyway when we tackle this issue. |
Hi, |
I think you can only declare whole sections and specific section types as unmanaged section, not single options. |
The handling of unmanaged sections (store/restore) currently doesn't take the order of sections into account. In the firewall config this can lead to a modified order of rules and thus to a different behaviour.
The text was updated successfully, but these errors were encountered: