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
Safer defaults for immutable znc config #30155
Conversation
I just lost all the options I configured in ZNC, because the mutable config was overwritten. I accept any suggestions on the way to implement this, but overwriting a mutable config by default seems weird. If we want to do this, we should ensure that ZNC does not allow to edit the config via the webmin when cfg.mutable is false.
@@ -379,7 +379,8 @@ in | |||
# If mutable, regenerate conf file every time. | |||
${optionalString (!cfg.mutable) '' | |||
${pkgs.coreutils}/bin/echo "znc is set to be system-managed. Now deleting old znc.conf file to be regenerated." | |||
${pkgs.coreutils}/bin/rm -f ${cfg.dataDir}/configs/znc.conf | |||
${pkgs.coreutils}/bin/echo "You can still recover you old config from '${cfg.dataDir}/configs/znc.conf.bak'." | |||
${pkgs.coreutils}/bin/mv ${cfg.dataDir}/configs/znc.conf{,.bak} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would only move it, if it is not a symlink to the nix store. Otherwise a second restart will overwrite you existing configuration. This also avoids moving if no mutable configuration has ever existed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is never a symlink because if the file is not writeable, znc fails at startup. When it is not mutable, the file is overwritten at startup from the nix store file. Hence the issue.
Znc does not support immutable configuration files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could copy it only if it differs from the reference store file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I would add a recognizable pattern in the file, which can be checked in the script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patching ZNC seems the sane way to go, wit an error message when trying to change settings. I do not see how a patter would help, as probably ZNC overwrites the config on exit and on config change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, not going to happen soon... znc/znc#975
I now think this is the safest way to go. Disabling immutability by default seems enough. This backup thing would have helped for me but is not that important if mutable is an opt-out.
There seems to be little need for backups if mutable becomes a voluntary opt-out.
I think this is quite simple now, but changing the default may surprise old users, is there some way to warn them ? |
An entry in release-notes can help. |
That would be here:
|
I just lost all the options I configured in ZNC, because the mutable config was overwritten.
I accept any suggestions on the way to implement this, but overwriting a mutable config by default seems weird. If we want to do this, we should ensure that ZNC does not allow to edit the config via the webmin when cfg.mutable is false.