Make znc.conf store all .registry files from modules. #301

New Issue

2026-10-05T04:11:39+02:00

adam commented

2026-10-05 04:11:39 +02:00

Instead of having multiple .registry files stored in various folders, just move them into the znc.conf.

Edit: After opening this issue, Wug and psychon brought up valid issues with my initial idea.

Instead of having everything in the znc.conf, allow each module has its own conf file nickserv.conf, autoop.conf, ect... located in the same folder as znc.conf. This would prevent someone from accidentally pasting passwords on some site when we try to debug somebodies issue. (Wug)

Currently when you unload a module, znc will leave the .registry file behind, this allows for the module to be reloaded in the future. Make nickserv.conf, ect.. do the same thing. Don't delete anything when the module is unloaded. (psychon)

Instead of having multiple .registry files stored in various folders, just move them into the znc.conf. Edit: After opening this issue, `Wug` and `psychon` brought up valid issues with my initial idea. Instead of having everything in the `znc.conf`, allow each module has its own conf file `nickserv.conf`, `autoop.conf`, ect... located in the same folder as `znc.conf`. This would prevent someone from accidentally pasting passwords on some site when we try to debug somebodies issue. (`Wug`) Currently when you unload a module, znc will leave the .registry file behind, this allows for the module to be reloaded in the future. Make `nickserv.conf`, ect.. do the same thing. Don't delete anything when the module is unloaded. (`psychon`)

adam closed this issue

2026-10-05 04:11:39 +02:00

adam commented

2026-10-05 04:11:40 +02:00

Request for reopening as this wasn't ever done.

Request for reopening as this wasn't ever done.

adam commented

2026-10-05 04:11:41 +02:00

This would be real nice. (With the amendments.)

People who are used to configuring daemons would expect that all the configuration could be done via config files (with fully documented format) even before running the daemon for the first time.
Requiring interactive commands to configure a daemon feels unnatural.

The existence of .registry files is not even documented on the Wiki, apart from being mentioned in a couple of Changelogs.
Same for the SaveConfig command.

The first time I installed ZNC, I wanted it to survive reboots, but the type of authentication I needed was only available through modules. I found no documentation on how to configure these modules to keep their settings across reboots.

Eventually I figured it out, but this is the first daemon that requires interactive configuration I've seen.

This would be real nice. (With the amendments.) People who are used to configuring daemons would expect that all the configuration could be done via config files (with fully documented format) even before running the daemon for the first time. Requiring interactive commands to configure a daemon feels unnatural. The existence of .registry files is not even documented on the Wiki, apart from being mentioned in a couple of Changelogs. Same for the SaveConfig command. The first time I installed ZNC, I wanted it to survive reboots, but the type of authentication I needed was only available through modules. I found no documentation on how to configure these modules to keep their settings across reboots. Eventually I figured it out, but this is the first daemon that *requires* interactive configuration I've seen.

adam commented

2026-10-05 04:11:42 +02:00

located in the same folder as znc.conf

They can't be in the same folder, because multiple instances of the same module can be loaded with possibly different settings. So the hierarchy thing is good, and necessary.

But I'd still vote for having the .registry files' various settings documented (and maybe reuse the format of znc.conf), so admins can prepare these files in advance, and without any interaction with the daemon.

Also the files should not be hidden.
They are usually the only file in the directory and don't add any clutter. It only makes them harder to spot.

The .conf extension is also a good idea because it makes it more clear that a SaveConfig command would save them too.

> located in the same folder as `znc.conf` They can't be in the same folder, because multiple instances of the same module can be loaded with possibly different settings. So the hierarchy thing is good, and necessary. But I'd still vote for having the .registry files' various settings documented (and maybe reuse the format of `znc.conf`), so admins can prepare these files in advance, and without any interaction with the daemon. Also the files should not be hidden. They are usually the only file in the directory and don't add any clutter. It only makes them harder to spot. The `.conf` extension is also a good idea because it makes it more clear that a Save**Conf**ig command would save them too.

adam commented

2026-10-05 04:11:42 +02:00

but the type of authentication I needed was only available through modules.

If I remember correctly, modules like nickserv also accept a password via the module argument.

But I'd still vote for having the .registry files' various settings documented

That would mean we cannot change the format any more. I'm not sure if that is really a good idea.

The .conf extension is also a good idea because it makes it more clear that a SaveConfig command would save them too.

It does not. The files are written immediately after a module changes the settings (unless it explicitly asks for the file not to be rewritten, in which case ZNC itself also never writes this).

> but the type of authentication I needed was only available through modules. If I remember correctly, modules like `nickserv` also accept a password via the module argument. > But I'd still vote for having the .registry files' various settings documented That would mean we cannot change the format any more. I'm not sure if that is really a good idea. > The .conf extension is also a good idea because it makes it more clear that a SaveConfig command would save them too. It does not. The files are written immediately after a module changes the settings (unless it explicitly asks for the file not to be rewritten, in which case ZNC itself also never writes this).

adam commented

2026-10-05 04:11:43 +02:00

But I'd still vote for having the .registry files' various settings documented

That would mean we cannot change the format any more

The format of znc.conf is documented, but you change it.
(And changes are reflected in the docs.)

but the type of authentication I needed was only available through modules.

If I remember correctly, modules like nickserv also accept a password via the module argument.

But the sasl module doesn't accept arguments, as far as I can tell. Only interactive commands.

>>But I'd still vote for having the .registry files' various settings documented > >That would mean we cannot change the format any more The format of `znc.conf` is documented, but you change it. (And changes are reflected in the docs.) >>but the type of authentication I needed was only available through modules. > >If I remember correctly, modules like nickserv also accept a password via the module argument. But the sasl module doesn't accept arguments, as far as I can tell. Only interactive commands.

adam commented

2026-10-05 04:11:44 +02:00

Better documentation won't hurt. These files have to be backwards-compatible anyway. Would you like to add details to wiki?

Better documentation won't hurt. These files have to be backwards-compatible anyway. Would you like to add details to wiki?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#301