The discussion over on bug 12805 (and specifically bug 12805, comment 5 from Viktor) got me thinking... Could we create a general purpose config editing script, at least for the <config> part of koha-conf.xml, instead of having specific scripts for lots of different config settings? If we added a (e.g.) YAML file with some metadata about the different setttings (a description, what kind of data it should contain), we could perhaps have a friendly tool that could - toggle settings off/on ("backup_db_via_tools is currently off, are you sure you want to enable it?") - offer options from a list (e.g. "dom" or "grs1" for the indexing modes) - validate the contents of fields (e.g. check that "port" gets a numeric value, or check that settings that take a path get a path that actually exists) Sample usage: Display all current settings: sudo koha-config -l <instancename> Display a specific setting: sudo koha-config <instancename> opacdir Change a specific setting: sudo koha-config <instancename> backup_db_via_tools=on (If backup_db_via_tools was already enabled, the script could say so and exit, if it was not enabled, it could verify that the user wants to change it, and make sure the value of the setting gets a 1. It could accept different input like "on", "1", "enable" etc) There could even be an interactive mode (sudo koha-config -i <instancename>) which would display something like a numbered list of current settings, let the user choose one and prompt for input, validate the input, display the changed setting etc. Of course, some config changes need more work than just changing the setting. If the user tries to e.g. enable plugins by changing the "enable_plugins" setting, the script could give a friendly warning that the user should instead use the koha-enable-plugins script. The script could perhaps take a --configfile parameter, so it could be used to edit configs for non-package-setups too. Would this just be a lot of work for little gain, or could it be a nice addition for making the threshold lower for inexperienced admins?
Setting this straight to "in discussion" :-)
> Would this just be a lot of work for little gain, or could it be a nice > addition for making the threshold lower for inexperienced admins? As an inexperienced admin I'm listening here and approve of all initiatives to make my life easier. However I must confess that even if I'm used to coding I never really took a liking to CLI. The really helpful thing would be to have a GUI that knows all the allowed values and lets me manipulate the settings and making shure they are saved in a valid format. I suspect there are interface libraries floating around on Cpan that take an XML file as input and creates something basic but functional(?) To be honest I was glad to leave the CLI of C64 for Amiga workbench. Not much cred in that, but the truth :) And over here most IT-librarians will be raised on MS-products.
(In reply to Magnus Enger from comment #0) > Could we create a general purpose config editing script, at least for the > <config> part of koha-conf.xml, instead of having specific scripts for lots > of different config settings? If we added a (e.g.) YAML file with some > metadata about the different setttings (a description, what kind of data it > should contain), we could perhaps have a friendly tool that could +1 it makes sense. something like this will also allow us to have an unified sanity check / reporting on the config. > There could even be an interactive mode (sudo koha-config -i <instancename>) > which would display something like a numbered list of current settings, let > the user choose one and prompt for input, validate the input, display the > changed setting etc. I was thinking, the default `sudo koha-config` could be the interactive mode ala python. @Viktor: while ^^^ not being a GUI, Magnus's suggestion of an interactive mode actually does pretty much what you are asking. Of course, if anyone volunteers, wrapping a dialog / gdialog / zenity wrapper around the bash script will give you the GUI :-) -indra
I like the idea of a CLI editor/querier for the config. As much as I'm not as anti-XML as many people, I don't think it's the sort of thing that should be hand edited if possible. I'll quibble over details a bit (e.g., they should behave like UNIX commands and be idempotent where possible, whereas your examples aren't, also shouldn't be interactive unless you explicitly ask) but overall it's worthwhile. One this this would lend itself to nicely is automatic configuration, via puppet or such. We might also want an XML schema to describe the config, and we can validate the user input against that perhaps. (Similar to the YAML idea, but it can be used to validate the resulting file in total.) It could be worth looking to the tools that modify the gconf registry for examples on how things should work, as they perform a similar task. gconftool and friends, although they're probably more complicated than we need. As for a GUI, that's not likely to happen. A text UI is fine (debconf-esque or something), but we're not going to ever be depending on a GUI subsystem for a server, servers shouldn't have a GUI. Also, rather than referring people to koha-enable-plugins etc., it should probably subsume them to keep things consistent. Other things to hash out are what happens to elements that can be repeated, nested, and so on.
> As for a GUI, that's not likely to happen. A text UI is fine (debconf-esque > or something), but we're not going to ever be depending on a GUI subsystem > for a server, servers shouldn't have a GUI. I'm not expecting any experienced Koha admins to approve of a GUI :) I must however confess that running my dev install on a regular desktop Debian while trying to learn what's under the hood makes it easier. So my thought was that a script would be good for actual admins that just wants to make shure things are correct, editing the files directly good for those who like to tinker with stuff and a GUI for real newbies coming from windows who just want to edit the settings on a test install without becoming friends with the terminal first. The suggestion was based on my interest in lowering the barriers for IT-librarians evaluating Koha as an alternative to proprietary systems since the very rarely has spent any real time in the terminal of a *nix OS. The same goes for most IT-departments here who refuse to touch anything that not MS. I'll back off on this now and enjoy watching the creation of a useful tool that I'll gladly use myself. @Indranil Interactive mode sound great. I guess that the day I can create a GUI wrapper myself I will find no use for it :)