[Whonix-devel] stackable wrapper, .d configuration drop-in folders

[Michael Stapelberg]

On Sun, Aug 25, 2019 at 11:10 AM Patrick Schleizer <adrelanos at riseup.net>
wrote:

> I enjoyed reading:
>
> Linux distributions: Can we do without hooks and triggers?
>
> https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-triggers/
>
> Also enjoyed watching:
>
> GPN19 - Linux package manager sind zu langsam!
>
> https://www.youtube.com/watch?v=TdfEF0zRIL4


Thanks! For those unfamiliar with this work, I think
https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/ might be
the best starting point :)


>
>
> Some comments.
>
> I find drop-in .d folders are of supreme usefulness. However, there are
> a few non-perfections.
>
> All of these drop-in folders work a bit different.
>
> config drop-in folder example:
>
> /etc/grub.d/
>
> script drop-in folder example:
>
> /etc/default/grub.d/
>
> Process files ending with '~' (created by editor backup files?) or
> 'dpkg-old'? I think should not.
>

In Debian, typically a specific suffix is required for the file to be
considered, which excludes all sorts of temporary replacements and backup
files. E.g., files in /etc/apt/sources.list.d/ require ending in .list.


>
> For the kernel, looks like there is maximum flexibility.
>
> /etc/kernel/header_postinst.d
> /etc/kernel/install.d
> /etc/kernel/postinst.d
> /etc/kernel/postrm.d
> /etc/kernel/preinst.d
> /etc/kernel/prerm.d
>
> For adduser, there is a nice feature request [1]:
> hooks: /etc/adduser/{pre,post}{user,group}{add,del}.d/
>
> But there doesn't seem to be a convention on how such drop-in folders
> should be constructed.
>

Indeed, I’m not aware of any codified best practices regarding .d
directories either. It would be great to write something down! I’d be happy
to review/contribute.


>
> One may have opinions on systemd but unrelated to that, I like how
> systemd supports drop-ins for virtually anything aiming at maximum
> flexibility.
>
> There also seems to be no convention where drop-in folders are located
> [/usr/lib|/lib] and /etc; or only in /etc.
>

I’d argue that systemd’s locations in that regard form a de-facto standard.


>
> It's non-ideal that every application is reinventing config parsing,
> drop-ins, hooks, etc.
>

Indeed, but that’s a much bigger battle ;). IMO, any guidelines regarding
.d parsing should be generic enough that they can easily be implemented in
any application. The first step is to unify behavior, and unifying
implementations can come later.


>
> I've wrote pre.bsh - a bash snippet which gets `source`ed by every
> Debian maintainer script I write. It simplifies and abstracts  debugging
> and customization. I wish similar functionality was already a default
> feature of dpkg.
>
> It would be good of wrappers were stackable. We called this stackable
> wrappers and starting explaining the issue as well as discussed
> potential solutions.
>
> https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt
>
> My Background: I am a maintainer of Whonix, which is a derivative of
> Whonix.
>
> cc'd whonix-devel mailing list so all our readers can benefit from you
> reply.
>
> Kind regards,
> Patrick
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019
> [2]
>
> https://github.com/Whonix/helper-scripts/blob/master/usr/lib/helper-scripts/pre.bsh
> [3]
> ## The idea of this bash fragment is:
> ## Say nothing, if everything goes well, but dump everything on error.
>
> ## It allows to easily look inside the xtrace of a (Debian maintainer)
> script,
> ## when the DEBDEBUG environment variable is set to 1.
>
> ## To use it in other scripts, use something like this:
> # if [ -f /usr/lib/helper-scripts/pre.bsh ]; then
> #    source /usr/lib/helper-scripts/pre.bsh
> # fi
>
> ## Error log:
> ## - implement trap ERR if function errorhandlergeneral does not exist
> ## - implements a simple error handler if non exists
> ## - run silent by default
> ## - write xtrace to temporary log
> ## - show full xtrace on unexpected non-zero exit code
> ## - show exit code on unexpected non-zero exit code
> ## - run syntax check "bash -n" on this script
> ## - run syntax check "bash -n" on the script that sourced this script
>
> ## DEBDEBUG:
> ##
> ## enable xtrace (-x) for maintainer script when DEBDEBUG environment
> ## variable is set to 1.
> ## For example:
> ##    sudo DEBDEBUG=1 dpkg -i /path/to/package.deb
>
> ## SKIP_SCRIPTS
> ##
> ## The SKIP_SCRIPTS environment variable to skip scripts by name
> ## For example:
> ##    sudo DEBDEBUG=1 SKIP_SCRIPTS=" security-misc.postinst " dpkg -i
> /path/to/package.deb
> ##
> ## another example:
> ##
> ##    export DEBDEBUG=1
> ##     export SKIP_SCRIPTS+=" security-misc.postinst "
> ##     sudo -E dpkg -i /path/to/package.deb
>
> ## Colorful output: provides color function
>
> ## Shell options: enables errtrace
>
> ## Configuration Folders
> ##
> ## For example if the name of the package is 'security-misc':
> ## - /etc/security-misc_maint.d/*.conf
> ## - /usr/local/etc/security-misc_maint.d/*.conf
> ##
> ## For example if the name of the script is 'panic-on-oops':
> ## - /etc/panic-on-oops_pre.d/*.conf
> ## - /usr/local/etc/panic-on-oops_pre.d/*.conf
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20190825/41562262/attachment.htm>