Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #51653 > unrolled thread

Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration

Back to article view | Back to linux.debian.kernel

Contents

  Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Guilhem Moulin <guilhem@guilhem.org> - 2015-12-10 03:00 +0100
    Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Guilhem Moulin <guilhem@guilhem.org> - 2015-12-10 03:40 +0100
    Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Jonas Meurer <jonas@freesources.org> - 2015-12-10 13:00 +0100
      Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Guilhem Moulin <guilhem@guilhem.org> - 2015-12-10 15:30 +0100
        Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Jonas Meurer <jonas@freesources.org> - 2015-12-10 16:20 +0100
      Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Ben Hutchings <ben@decadent.org.uk> - 2015-12-11 02:00 +0100
        Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Guilhem Moulin <guilhem@guilhem.org> - 2015-12-11 15:40 +0100
          Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Jonas Meurer <jonas@freesources.org> - 2015-12-17 10:10 +0100
            Bug#807527: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Jonas Meurer <jonas@freesources.org> - 2015-12-23 23:20 +0100
              Bug#807527: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration Jonas Meurer <jonas@freesources.org> - 2015-12-25 15:00 +0100
    Processed: [PATCH initramfs-tools 3/3] initramfs-tools.8: Add  brief description of configuration hooks and files owner@bugs.debian.org (Debian Bug Tracking System) - 2016-01-25 18:30 +0100
    Bug#807527: marked as done (initramfs-tools: Please provide an  API or best practices for custom initramfs hook configuration) owner@bugs.debian.org (Debian Bug Tracking System) - 2016-02-11 05:40 +0100

#51653 — Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration

[Multipart message — attachments visible in raw view] — view raw

Package: initramfs-tools
Severity: normal
X-Debug-CC: pkg-cryptsetup-devel@lists.alioth.debian.org

Dear Maintainer,

AFAIK there is no documentation for where users should set variables to
configure an initramfs hook.  There are a couple of workaround, all
hacky and/or relying on undocumented properties of initramfs-tools(8):

  1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
     are executed is sub-shells the variable need to be exported.)  This
     is somewhat ugly since initramfs.conf(5) is the configuration file
     *for mkinitramfs*, not for the hook files.

  2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
     undocumented (short of an entry in the changelog) hack.  Also
     unless that file is marked as a conffile (which violates the
     policy) user modifications are wiped upon upgrade.

  3/ Make /usr/share/initramfs-tools/conf-hooks.d/$hook a symlink to
     /etc/initramfs-tools/conf-hooks.d/$hook.  But again, this uses an
     undocumented property of mkinitramfs(8), and it might hijack your
     /etc/initramfs-tools namespace.

There are packages that ship user configurable initramfs hooks
(cryptsetup and dropbear-initramfs come to mind).  These package need
documented instructions for where to drop user configuration
(/etc/initramfs-tools/conf-hooks.d/$package comes to mind).

Alternatively, in a private discussion with Jonas Meurer of the Debian
Cryptsetup Team (X-Debug-CC), I've been suggested that mkinitramfs(8)
could instead source files in /etc/initramfs-tools/conf-hooks.d/ after
sourcing /usr/share/initramfs-tools/conf-hooks.d/.  This way package
maintainers would ship variables with their default in /usr while users
would write their custom configuration in /etc.

-8<----------------------------------------------------->8-
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -87,6 +87,7 @@
 		echo "Warning: ${i} is a directory instead of file, ignoring."
 	elif [ -e "${i}" ]; then
 		. "${i}"
+		. [ ! -f "/etc/${i#/usr/share/}" ] || . "/etc/${i#/usr/share/}"
 	fi
 done
 
-8<----------------------------------------------------->8-

Either way, IMHO initramfs-tools(8) should include some instructions for
custom initramfs hook configuration.

Cheers,
-- 
Guilhem.

PS. In fact I've implemented 3/ in dropbear-initramfs a couple of weeks
    ago.  Oops…

[toc] | [next] | [standalone]

#51655

[Multipart message — attachments visible in raw view] — view raw

s/X-Debug-CC/X-Debbugs-CC/

-- 
Guilhem.

[toc] | [prev] | [next] | [standalone]

#51673

[Multipart message — attachments visible in raw view] — view raw

Hi there,

On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin <guilhem@guilhem.org>
wrote:
> AFAIK there is no documentation for where users should set variables to
> configure an initramfs hook.  There are a couple of workaround, all
> hacky and/or relying on undocumented properties of initramfs-tools(8):
> 
>   1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
>      are executed is sub-shells the variable need to be exported.)  This
>      is somewhat ugly since initramfs.conf(5) is the configuration file
>      *for mkinitramfs*, not for the hook files.
> 
>   2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
>      undocumented (short of an entry in the changelog) hack.  Also
>      unless that file is marked as a conffile (which violates the
>      policy) user modifications are wiped upon upgrade.

If I got it right (didn't find documentation about it), the current
purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
proper way required by the hook scripts, not to set configuration
variables for the hook scripts themselves, no? At least, all that
mkinitramfs does for now, is to source the files from conf-hooks.d. No
export of variables, so the configured variables aren't available to the
hook scripts for now.

>   3/ Make /usr/share/initramfs-tools/conf-hooks.d/$hook a symlink to
>      /etc/initramfs-tools/conf-hooks.d/$hook.  But again, this uses an
>      undocumented property of mkinitramfs(8), and it might hijack your
>      /etc/initramfs-tools namespace.
> 
> There are packages that ship user configurable initramfs hooks
> (cryptsetup and dropbear-initramfs come to mind).  These package need
> documented instructions for where to drop user configuration
> (/etc/initramfs-tools/conf-hooks.d/$package comes to mind).
> 
> Alternatively, in a private discussion with Jonas Meurer of the Debian
> Cryptsetup Team (X-Debug-CC), I've been suggested that mkinitramfs(8)
> could instead source files in /etc/initramfs-tools/conf-hooks.d/ after
> sourcing /usr/share/initramfs-tools/conf-hooks.d/.  This way package
> maintainers would ship variables with their default in /usr while users
> would write their custom configuration in /etc.

Following up on that I think that a proper solution would be the following:

- redefine the purpose of files in conf-hooks.d to set variables that
  are made available to mkinitramfs *and* the hook scripts. In other
  words, parse the configure includes from conf-hooks.d in mkinitramfs
  and export all variables instead of just sourcing the files.
- add the change proposed by Guilhem and support user-defined configs
  from /etc/initramfs-tools/conf-hooks.d/, overwriting the configs from
  packages at /usr/share/initramfs-tools/conf-hooks.d/.

See attached patch which implements this.

Cheers,
 jonas

> -8<----------------------------------------------------->8-
> --- a/mkinitramfs
> +++ b/mkinitramfs
> @@ -87,6 +87,7 @@
>  		echo "Warning: ${i} is a directory instead of file, ignoring."
>  	elif [ -e "${i}" ]; then
>  		. "${i}"
> +		. [ ! -f "/etc/${i#/usr/share/}" ] || . "/etc/${i#/usr/share/}"
>  	fi
>  done
>  
> -8<----------------------------------------------------->8-
> 
> Either way, IMHO initramfs-tools(8) should include some instructions for
> custom initramfs hook configuration.
> 
> Cheers,
> -- 
> Guilhem.
> 
> PS. In fact I've implemented 3/ in dropbear-initramfs a couple of weeks
>     ago.  Oops…

[toc] | [prev] | [next] | [standalone]

#51674

[Multipart message — attachments visible in raw view] — view raw

On Thu, 10 Dec 2015 at 12:15:33 +0100, Jonas Meurer wrote:
> - redefine the purpose of files in conf-hooks.d to set variables that
> are made available to mkinitramfs *and* the hook scripts.

On second thought it might not be ideal to use the same file for both,
as exporting all variable to the hooks can have unexpected side effects.

For instance the dropbear hook changes the default UMASK value to 0077
in order to protect the private key material (the SSH host keys).  But
this variable is also used by other software to override the process's
umask(2); if it were to be set in the hooks, files within the initramfs
image might be created with the wrong permissions, which is certainly
not intended and might have unexpected side effects.

> # source package confs
> -for i in /usr/share/initramfs-tools/conf-hooks.d/*; do
> +for i in /usr/share/initramfs-tools/conf-hooks.d/* /etc/initramfs-tools/conf-hooks.d/*; do
>  if [ -d "${i}" ]; then
>      echo "Warning: ${i} is a directory instead of file, ignoring."
>  elif [ -e "${i}" ]; then
>      . "${i}"
> +     hookvars="$(sed -e '/#.*$/d' -e '/^$/d' ${i} | cut -d= -f1)"
> +     if [ -n "${hookvars}" ]; then
> +         export ${hookvars}
> +     fi
>  fi
> done

If *all* variables are accessible in *all* hooks there must be some kind
of policy to prevents collisions.  For instance packages a and b
shouldn't make use the same variable OPTIONS, since the assignment in
conf-hooks.d/b would override that in conf-hooks.d/a.


I should also add that Jonas and I would both like to avoid the easy &
dirty solution consisting of making the package ship a configuration
file for its hook in /etc/$package/initramfs-hook and source that file
in the hook.  Some cleaner organization in the fashion of /etc/default
seems like the way to go.

-- 
Guilhem.

[toc] | [prev] | [next] | [standalone]

#51675

[Multipart message — attachments visible in raw view] — view raw

Am 10.12.2015 um 15:18 schrieb Guilhem Moulin:
> On Thu, 10 Dec 2015 at 12:15:33 +0100, Jonas Meurer wrote:
>> - redefine the purpose of files in conf-hooks.d to set variables that
>> are made available to mkinitramfs *and* the hook scripts.
> 
> On second thought it might not be ideal to use the same file for both,
> as exporting all variable to the hooks can have unexpected side effects.
> 
> For instance the dropbear hook changes the default UMASK value to 0077
> in order to protect the private key material (the SSH host keys).  But
> this variable is also used by other software to override the process's
> umask(2); if it were to be set in the hooks, files within the initramfs
> image might be created with the wrong permissions, which is certainly
> not intended and might have unexpected side effects.

Agreed. I updated the patch to do the following:

- source all files from conf-hooks.d/* at the beginning of mkinitramfs
  just as before (but adding the files from ${CONFDIR}/conf-hooks.d/*).
- export variables from conf-hooks.d/<hook> just before the hook script
  hooks/<hook> is executed.

This should mitigate the described side-effects.

See the updated patch attached to this mail.

>> # source package confs
>> -for i in /usr/share/initramfs-tools/conf-hooks.d/*; do
>> +for i in /usr/share/initramfs-tools/conf-hooks.d/* /etc/initramfs-tools/conf-hooks.d/*; do
>>  if [ -d "${i}" ]; then
>>      echo "Warning: ${i} is a directory instead of file, ignoring."
>>  elif [ -e "${i}" ]; then
>>      . "${i}"
>> +     hookvars="$(sed -e '/#.*$/d' -e '/^$/d' ${i} | cut -d= -f1)"
>> +     if [ -n "${hookvars}" ]; then
>> +         export ${hookvars}
>> +     fi
>>  fi
>> done
> 
> If *all* variables are accessible in *all* hooks there must be some kind
> of policy to prevents collisions.  For instance packages a and b
> shouldn't make use the same variable OPTIONS, since the assignment in
> conf-hooks.d/b would override that in conf-hooks.d/a.
> 
> 
> I should also add that Jonas and I would both like to avoid the easy &
> dirty solution consisting of making the package ship a configuration
> file for its hook in /etc/$package/initramfs-hook and source that file
> in the hook.  Some cleaner organization in the fashion of /etc/default
> seems like the way to go.

Yep :)

Cheers
 jonas

[toc] | [prev] | [next] | [standalone]

#51685

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2015-12-10 at 12:15 +0100, Jonas Meurer wrote:
> Hi there,
> 
> On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin 
> wrote:
> > AFAIK there is no documentation for where users should set variables to
> > configure an initramfs hook.  There are a couple of workaround, all
> > hacky and/or relying on undocumented properties of initramfs-tools(8):
> > 
> >   1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
> >      are executed is sub-shells the variable need to be exported.)  This
> >      is somewhat ugly since initramfs.conf(5) is the configuration file
> >      *for mkinitramfs*, not for the hook files.
> > 
> >   2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
> >      undocumented (short of an entry in the changelog) hack.  Also
> >      unless that file is marked as a conffile (which violates the
> >      policy) user modifications are wiped upon upgrade.
> 
> If I got it right (didn't find documentation about it), the current
> purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
> proper way required by the hook scripts, not to set configuration
> variables for the hook scripts themselves, no?

The only documentation I'm aware of is in the changelog:

  * mkinitramfs: Export MODULES, allows hook scripts to act accordingly.
    (closes: #421658) Add /usr/share/initramfs-tools/conf-hooks.d for hooks
    options on mkinitramfs run. Do not land in initramfs.

[...]
> - redefine the purpose of files in conf-hooks.d to set variables that
>   are made available to mkinitramfs *and* the hook scripts. In other
>   words, parse the configure includes from conf-hooks.d in mkinitramfs
>   and export all variables instead of just sourcing the files.
[...]

No, I am not going to add any more half-baked shell script parsing.

Also, it doesn't make any sense to me, to put hook-specific
configuration into a namespace shared across all hooks.  You can
always add a configuration file to your own package and source it in
your hook script.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

[toc] | [prev] | [next] | [standalone]

#51698

[Multipart message — attachments visible in raw view] — view raw

On Fri, 11 Dec 2015 at 00:54:03 +0000, Ben Hutchings wrote:
> On Thu, 2015-12-10 at 12:15 +0100, Jonas Meurer wrote:
>> Hi there,
>> 
>> On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin 
>> wrote:
>>> AFAIK there is no documentation for where users should set variables to
>>> configure an initramfs hook.  There are a couple of workaround, all
>>> hacky and/or relying on undocumented properties of initramfs-tools(8):
>>> 
>>>   1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
>>>      are executed is sub-shells the variable need to be exported.)  This
>>>      is somewhat ugly since initramfs.conf(5) is the configuration file
>>>      *for mkinitramfs*, not for the hook files.
>>> 
>>>   2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
>>>      undocumented (short of an entry in the changelog) hack.  Also
>>>      unless that file is marked as a conffile (which violates the
>>>      policy) user modifications are wiped upon upgrade.
>> 
>> If I got it right (didn't find documentation about it), the current
>> purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
>> proper way required by the hook scripts, not to set configuration
>> variables for the hook scripts themselves, no?
> 
> The only documentation I'm aware of is in the changelog:
> 
>   * mkinitramfs: Export MODULES, allows hook scripts to act accordingly.
>     (closes: #421658) Add /usr/share/initramfs-tools/conf-hooks.d for hooks
>     options on mkinitramfs run. Do not land in initramfs.

Please consider adding it to the mkinitramfs manpage, too.  Package
maintainers can't rely on something that's only documented in the
manpage, IMHO.
 
> Also, it doesn't make any sense to me, to put hook-specific
> configuration into a namespace shared across all hooks.  You can
> always add a configuration file to your own package and source it in
> your hook script.

Using /etc/$package/initramfs adds a useless directory level for
packages that only ship initramfs hook and script.  The directory
/etc/default is shared, also.

-- 
Guilhem.

[toc] | [prev] | [next] | [standalone]

#51782

[Multipart message — attachments visible in raw view] — view raw

Am 11.12.2015 um 15:35 schrieb Guilhem Moulin:
> On Fri, 11 Dec 2015 at 00:54:03 +0000, Ben Hutchings wrote:
>> On Thu, 2015-12-10 at 12:15 +0100, Jonas Meurer wrote:
>>> Hi there,
>>>
>>> On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin 
>>> wrote:
>>>> AFAIK there is no documentation for where users should set variables to
>>>> configure an initramfs hook.  There are a couple of workaround, all
>>>> hacky and/or relying on undocumented properties of initramfs-tools(8):
>>>>
>>>>   1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
>>>>      are executed is sub-shells the variable need to be exported.)  This
>>>>      is somewhat ugly since initramfs.conf(5) is the configuration file
>>>>      *for mkinitramfs*, not for the hook files.
>>>>
>>>>   2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
>>>>      undocumented (short of an entry in the changelog) hack.  Also
>>>>      unless that file is marked as a conffile (which violates the
>>>>      policy) user modifications are wiped upon upgrade.
>>>
>>> If I got it right (didn't find documentation about it), the current
>>> purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
>>> proper way required by the hook scripts, not to set configuration
>>> variables for the hook scripts themselves, no?
>>
>> The only documentation I'm aware of is in the changelog:
>>
>>   * mkinitramfs: Export MODULES, allows hook scripts to act accordingly.
>>     (closes: #421658) Add /usr/share/initramfs-tools/conf-hooks.d for hooks
>>     options on mkinitramfs run. Do not land in initramfs.
> 
> Please consider adding it to the mkinitramfs manpage, too.  Package
> maintainers can't rely on something that's only documented in the
> manpage, IMHO.

I guess that Guilhem meant "... something that's only documented in the
changelog". And I agree with him, that the purpose and limitations of
conf-hooks.d directory should be properly documented somewhere in the
mkinitramfs(8) manpage.

>> No, I am not going to add any more half-baked shell script parsing.
>> 
>> Also, it doesn't make any sense to me, to put hook-specific
>> configuration into a namespace shared across all hooks.  You can
>> always add a configuration file to your own package and source it in
>> your hook script.
> 
> Using /etc/$package/initramfs adds a useless directory level for
> packages that only ship initramfs hook and script.  The directory
> /etc/default is shared, also.

I understand that Ben will not add the solution that we prefer and
suggest. But I still believe that some "standardized" way to make a
initramfs hook script configurable would be a benefit.

Especially I don't like the idea to add yet another new config file for
the hook scripts. Thus I suggest the following: in cryptsetup, we use
the conf-hook.d/cryptroot file for both the main mkinitramfs and the
hook script configuration. Variables for the hook script will use a
special namespace (like CRYPTROOT_*) and will be exported. Moulin could
use the same scheme for dropbear (with DROPBEAR_* namespace).

Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d
equivalent directory in addition to
/usr/share/initramfs-tools/conf-hooks.d? That way, at least custom
changes of the hook script config would be supported in a proper way.

If we can agree on that, then the following changes would be needed in
initramfs-tools:

1/ add support for /etc/initramfs-tools/conf-hooks.d (already
   implemented in the patch I submitted)
2/ properly document purpose and limitations of conf-hooks.d directories

Cheers
 jonas

[toc] | [prev] | [next] | [standalone]

#51859 — Bug#807527: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,

Am 17.12.2015 um 09:57 schrieb Jonas Meurer:
> Am 11.12.2015 um 15:35 schrieb Guilhem Moulin:
>> On Fri, 11 Dec 2015 at 00:54:03 +0000, Ben Hutchings wrote:
> I guess that Guilhem meant "... something that's only documented in the
> changelog". And I agree with him, that the purpose and limitations of
> conf-hooks.d directory should be properly documented somewhere in the
> mkinitramfs(8) manpage.

Do you agree?

>>> No, I am not going to add any more half-baked shell script parsing.
>>>
>>> Also, it doesn't make any sense to me, to put hook-specific
>>> configuration into a namespace shared across all hooks.  You can
>>> always add a configuration file to your own package and source it in
>>> your hook script.
>>
>> Using /etc/$package/initramfs adds a useless directory level for
>> packages that only ship initramfs hook and script.  The directory
>> /etc/default is shared, also.
> 
> I understand that Ben will not add the solution that we prefer and
> suggest. But I still believe that some "standardized" way to make a
> initramfs hook script configurable would be a benefit.
> 
> Especially I don't like the idea to add yet another new config file for
> the hook scripts. Thus I suggest the following: in cryptsetup, we use
> the conf-hook.d/cryptroot file for both the main mkinitramfs and the
> hook script configuration. Variables for the hook script will use a
> special namespace (like CRYPTROOT_*) and will be exported. Moulin could
> use the same scheme for dropbear (with DROPBEAR_* namespace).
> 
> Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d
> equivalent directory in addition to
> /usr/share/initramfs-tools/conf-hooks.d? That way, at least custom
> changes of the hook script config would be supported in a proper way.
> 
> If we can agree on that, then the following changes would be needed in
> initramfs-tools:
> 
> 1/ add support for /etc/initramfs-tools/conf-hooks.d (already
>    implemented in the patch I submitted)
> 2/ properly document purpose and limitations of conf-hooks.d directories

Ben, what's your opinion on this suggestion? Is it an acceptable
solution for you? Or do you prefer to not change anything regarding
conf-hooks.d directory handing in mkinitramfs?

Cheers
 jonas

[toc] | [prev] | [next] | [standalone]

#51874 — Bug#807527: [pkg-cryptsetup-devel] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration

[Multipart message — attachments visible in raw view] — view raw

Am 23.12.2015 um 23:15 schrieb Jonas Meurer:
> Am 17.12.2015 um 09:57 schrieb Jonas Meurer:
>> Am 11.12.2015 um 15:35 schrieb Guilhem Moulin:
>>> On Fri, 11 Dec 2015 at 00:54:03 +0000, Ben Hutchings wrote:
>> I guess that Guilhem meant "... something that's only documented in the
>> changelog". And I agree with him, that the purpose and limitations of
>> conf-hooks.d directory should be properly documented somewhere in the
>> mkinitramfs(8) manpage.
> 
> Do you agree?
> 
>>>> No, I am not going to add any more half-baked shell script parsing.
>>>>
>>>> Also, it doesn't make any sense to me, to put hook-specific
>>>> configuration into a namespace shared across all hooks.  You can
>>>> always add a configuration file to your own package and source it in
>>>> your hook script.
>>>
>>> Using /etc/$package/initramfs adds a useless directory level for
>>> packages that only ship initramfs hook and script.  The directory
>>> /etc/default is shared, also.
>>
>> I understand that Ben will not add the solution that we prefer and
>> suggest. But I still believe that some "standardized" way to make a
>> initramfs hook script configurable would be a benefit.
>>
>> Especially I don't like the idea to add yet another new config file for
>> the hook scripts. Thus I suggest the following: in cryptsetup, we use
>> the conf-hook.d/cryptroot file for both the main mkinitramfs and the
>> hook script configuration. Variables for the hook script will use a
>> special namespace (like CRYPTROOT_*) and will be exported. Moulin could
>> use the same scheme for dropbear (with DROPBEAR_* namespace).
>>
>> Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d
>> equivalent directory in addition to
>> /usr/share/initramfs-tools/conf-hooks.d? That way, at least custom
>> changes of the hook script config would be supported in a proper way.
>>
>> If we can agree on that, then the following changes would be needed in
>> initramfs-tools:
>>
>> 1/ add support for /etc/initramfs-tools/conf-hooks.d (already
>>    implemented in the patch I submitted)
>> 2/ properly document purpose and limitations of conf-hooks.d directories
> 
> Ben, what's your opinion on this suggestion? Is it an acceptable
> solution for you? Or do you prefer to not change anything regarding
> conf-hooks.d directory handing in mkinitramfs?

After taking bugreport #783297[1] into consideration, the suggested
solution doesn't look sufficient any more.

Instead, the initramfs-tools documentation should make clear that hook
scripts *must not* source initramfs.conf without sourcing all files from
hook-conf.d/* as well.

Probably a separate configuration file is the cleanest solution for hook
scripts that need to be configurable. But in that case, I do think that
initramfs-tools should provide a place for hook configuration files.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783297

Cheers
 jonas

[toc] | [prev] | [next] | [standalone]

#52433 — Processed: [PATCH initramfs-tools 3/3] initramfs-tools.8: Add brief description of configuration hooks and files

Processing control commands:

> tag -1 patch pending
Bug #807527 [initramfs-tools] initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
Added tag(s) patch and pending.

-- 
807527: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#52791 — Bug#807527: marked as done (initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Thu, 11 Feb 2016 04:30:08 +0000
with message-id <E1aTitM-0005iQ-B0@franck.debian.org>
and subject line Bug#807527: fixed in initramfs-tools 0.123
has caused the Debian Bug report #807527,
regarding initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
807527: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web