<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:DengXian;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Segoe UI Symbol";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
        {font-family:"\@DengXian";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I’ve been thinking a bit about this lately. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>At the development level, we should be able to push out new configuration with new releases.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>While it’s only tangentially related, one way I do that when using the Catalyst framework is to use this plugin: <a href="https://metacpan.org/pod/Catalyst::Plugin::ConfigLoader#get_config_local_suffix">https://metacpan.org/pod/Catalyst::Plugin::ConfigLoader#get_config_local_suffix</a>. 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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But that’s just my 2 cents.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>David Cook<o:p></o:p></p><p class=MsoNormal>Systems Librarian<o:p></o:p></p><p class=MsoNormal>Prosentient Systems<o:p></o:p></p><p class=MsoNormal>72/330 Wattle St<o:p></o:p></p><p class=MsoNormal>Ultimo, NSW 2007<o:p></o:p></p><p class=MsoNormal>Australia<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Koha-devel <koha-devel-bounces@lists.koha-community.org> <b>On Behalf Of </b>Tomas Cohen Arazi<br><b>Sent:</b> Friday, 20 March 2020 12:46 AM<br><b>To:</b> Kyle Hall <kyle.m.hall@gmail.com><br><b>Cc:</b> koha-devel <koha-devel@lists.koha-community.org><br><b>Subject:</b> Re: [Koha-devel] Koha:::Logger configuration maintenance<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Thanks for your answer, Kyle.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>El jue., 19 mar. 2020 a las 10:18, Kyle Hall (<<a href="mailto:kyle.m.hall@gmail.com">kyle.m.hall@gmail.com</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal>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?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><span style='font-size:12.0pt'>---<o:p></o:p></span></p></div></div><div><p class=MsoNormal><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<o:p></o:p></p></div></div></div></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Mar 19, 2020 at 8:29 AM Tomas Cohen Arazi <<a href="mailto:tomascohen@gmail.com" target="_blank">tomascohen@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>Would you accept something like appending the new configuration bit on already created instances? During upgrade?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>for i in $(koha-list); do<o:p></o:p></p></div><div><p class=MsoNormal>    cat "the entries" >> /etc/koha/sites/$i/log4perl.conf<o:p></o:p></p></div><div><p class=MsoNormal>done<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The same will happen for SIP and other targets... <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Oh, and I noticed we didn't consider this for the Z39.50 responder :-/<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>El lun., 16 mar. 2020 a las 16:55, Tomas Cohen Arazi (<<a href="mailto:tomascohen@gmail.com" target="_blank">tomascohen@gmail.com</a>>) escribió:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Has anyone thought about this update problem? Ideas?<br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Tomás Cohen Arazi<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Theke Solutions (<a href="http://theke.io/" target="_blank">http://theke.io</a>)<br></span><span style='font-size:9.5pt;font-family:"Segoe UI Symbol",sans-serif'>✆</span><span style='font-size:9.5pt'> +54 9351 3513384<br>GPG: B2F3C15F<o:p></o:p></span></p></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Tomás Cohen Arazi<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Theke Solutions (<a href="http://theke.io/" target="_blank">http://theke.io</a>)<br></span><span style='font-size:9.5pt;font-family:"Segoe UI Symbol",sans-serif'>✆</span><span style='font-size:9.5pt'> +54 9351 3513384<br>GPG: B2F3C15F<o:p></o:p></span></p></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Koha-devel mailing list<br><a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br><a href="https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><o:p></o:p></p></blockquote></div></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Tomás Cohen Arazi<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Theke Solutions (<a href="http://theke.io/" target="_blank">http://theke.io</a>)<br></span><span style='font-size:9.5pt;font-family:"Segoe UI Symbol",sans-serif'>✆</span><span style='font-size:9.5pt'> +54 9351 3513384<br>GPG: B2F3C15F<o:p></o:p></span></p></div></div></div></div></div></div></body></html>