[Koha-devel] Koha:::Logger configuration maintenance

Fri Mar 20 01:09:26 CET 2020

I’ve been thinking a bit about this lately. 

At the development level, we should be able to push out new configuration with new releases.

At the implementation/deployment level, we should be able to customize that configuration, but then it seems like it is the implementor’s responsibility for maintaining those customizations. 

While it’s only tangentially related, one way I do that when using the Catalyst framework is to use this plugin: https://metacpan.org/pod/Catalyst::Plugin::ConfigLoader#get_config_local_suffix. As a Dev, I’ll create myapp.yml with all the latest and greatest configuration. Then as Ops I deploy a myapp_local.yml file which actually only contains a subset of configuration keys that I want to overwrite. I then manage the myapp_local.yml file by other means like Ansible or Docker Compose. 

Tomas’s patch sounds practical, but I wonder if we should be touching instance level data from the release level.  But if we don’t, then many people using Koha (without suitable support) won’t ever get upgraded configuration. Although if we always replaced non-local configuration with the release, that would get around that. 

Personally, I’d love to remove all the non-Zebra stuff out of koha-conf.xml (leaving it as just a Zebra configuration file) and create a koha-conf.yml file. (And if we did that, then that Catalyst::Plugin::ConfigLoader concept could work really nicely.)

But that’s just my 2 cents.

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Online: 02 8005 0595

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Tomas Cohen Arazi
Sent: Friday, 20 March 2020 12:46 AM
To: Kyle Hall <kyle.m.hall at gmail.com>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Koha:::Logger configuration maintenance

Thanks for your answer, Kyle.

The problem is that the Debian check works for files the installer puts on the FS, but not for the instance's ones we create ourselves.

I'm crafting a little patch for koha-common.postinst that checks for the instance's log4perl.conf checking if there's an entry for the component, and appends it otherwise.

Will submit it as part of bug 24905, which is the first time we need to patch things (already in 19.11, the z39.50 responder).

El jue., 19 mar. 2020 a las 10:18, Kyle Hall (<kyle.m.hall at gmail.com <mailto:kyle.m.hall at gmail.com> >) escribió:

Tomas, I think the general idea is the same as for koha-conf.xml. The current log4perl.conf has been forwards compatible. We could add new recommendations for updating the log4perl.conf to the release notes and such. Other Debian packages check to see if a config has been altered and decide if they should auto-update it based on that. Should we be doing something like that?

---

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Thu, Mar 19, 2020 at 8:29 AM Tomas Cohen Arazi <tomascohen at gmail.com <mailto:tomascohen at gmail.com> > wrote:

Would you accept something like appending the new configuration bit on already created instances? During upgrade?

for i in $(koha-list); do

    cat "the entries" >> /etc/koha/sites/$i/log4perl.conf

done

The same will happen for SIP and other targets... 

Oh, and I noticed we didn't consider this for the Z39.50 responder :-/

El lun., 16 mar. 2020 a las 16:55, Tomas Cohen Arazi (<tomascohen at gmail.com <mailto:tomascohen at gmail.com> >) escribió:

Hi all. I'm not that familiar with our Koha::Logger class usage, but I noticed there's no 'api' target and it would be handy to have it. There's a bug for a 'sip' target and for other things. It looks like the main reason for adopting log4perl was the flexibility it provided, and it makes sense: many appenders, several options, centralized config, etc.

The question is: how do we update people's config? We cannot just go edit their configs, right? The current log4perl.conf on each instance is generated using the template and adjusting the instance name.

Has anyone thought about this update problem? Ideas?

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200320/4522ec5c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200320/4522ec5c/attachment.sig>