Technicalities: Customizing (NUT) config files and scripts delivered by packaging

Debian divert

Supports "diverting" packaged files, so that package updates of those fall into files stored elsewhere while not impacting your actual fine-tuned setup (thanks to m4t on IRC for the suggestion):

:; dpkg-divert --local --rename --divert /bin/upssched-cmd.diverted --add /bin/upssched-cmd
:; cp -a /bin/upssched-cmd.diverted /bin/upssched-cmd

### Customize your newly independent /bin/upssched-cmd

Generally this trick can be used to move a packaged binary somewhere else and replace it with a wrapper script that sets environment variables and/or command line flags and exec's the real thing. (Hacking a custom LD_PRELOAD or debugging comes to mind.)

Normally for most of the NUT related scripting you are encouraged to customize the configuration files and point the SHUTDOWNCMD, CMDSCRIPT etc. to the custom filename which just does not conflict with packaging.

SystemD drop-in snippets

You don't have to (or rather even should not) rewrite packaged *.service and related files directly.

On one hand, SystemD supports a hierarchy of unit definitions (rising in priority from packaged {/usr,}/lib/systemd/system/ to site-local /etc/systemd/system/ to run-time /run/systemd/system/ which technically allows you to copy packaged files and customize them locally). On another, it also allows drop-in files which overlay a standard service or instance definition to tune it locally - by creating a directory like .../systemd/system/FULLUNITNAME.d/ and files named something.conf in it with the unit definition nuances you want to tune.

You can note that NUT's own nut-driver-enumerator (NDE) makes extensive use of this feature to maintain dependencies for nut-driver@... instances depending on device media type.

See also

• Building NUT for in-place upgrades or non-disruptive tests