maintain configuration files as separate files

[René Hummen]

The configuration files of hipd, hipfw and related HIPL programs are currently maintained in-source at hipd/init.c.

Examples are:
- HIPL_CONFIG_FILE_EX
- HIPL_HOSTS_FILE_EX
- HIPL_NSUPDATE_CONF_FILE_EX
- hip_init_certs()

This is ugly and leads to the side-effect that hipd needs to be run for the first time before hipfw can be started, as it needs to generate firewall_config. Furthermore, as the configuration files are not explicitly shipped in the distribution packages, they will not be removed on purge.

We need to maintain configuration in separate files, add them to configure.ac and ensure that the configuration files can also be found in case of running hipd from source without prior make install.

[Miika Komu (miika-iki)]

How are you planning to resolve this for people not using binary packages but only the sources?

[René Hummen (rene-hummen)]

hipd and other components should first check for _configuration_ files in the current directory (i.e., from source) and then in /etc/hip or /usr/local/etc/hip corresponding to the setup (i.e., when installed). Note that the storage location of the keys will not be touched by this change.

[Miika Komu (miika-iki)]

I see and agree now.

[Stefan Götz (stefan.goetz-deactivatedaccount)]

I think the usual approach of most other daemons is

1) search for the config file at the configured and compiled-in location (usually /etc or /usr/local/etc)

2) search for the config file in a user-specific location (not applicable with HIPL) or the working directory

It depends on the daemon whether they skip step 2) if step 1) succeeds or whether they read file 2) in addition to file 1). I guess the skipping approach makes the most sense for HIPL?

It might make sense to add a etc/hip directory to the source tree. It might also make sense to move all source code into a common src/ sub-directory (this is what a lot of projects do) (I know unrelated to this bug report).

[Diego Biurrun (diego-biurrun)]

On Wed, Jan 05, 2011 at 11:41:26AM +0000, Stefan Götz wrote:
> I think the usual approach of most other daemons is
>
> 1) search for the config file at the configured and compiled-in location
> (usually /etc or /usr/local/etc)
>
> 2) search for the config file in a user-specific location (not
> applicable with HIPL) or the working directory
>
> It depends on the daemon whether they skip step 2) if step 1) succeeds
> or whether they read file 2) in addition to file 1). I guess the
> skipping approach makes the most sense for HIPL?

Something along these lines is the only sensible solution. A daemon
should read a config file from a fixed location and accept a -f (or
similar) parameter on the command line to read the config file from
some other place.

Diego

[Miika Komu (miika-iki)]

Or maybe a -d as in configuration directory.

What happens if no configuration is not found? For example, if I just download the sources and start hipd in the source tree?

(In an ideal situation, the boot strapping procedure is completely zero-conf)

[Stefan Götz (stefan.goetz-deactivatedaccount)]

When no config file is found, most programs rely on built-in defaults whereas many daemons (e.g., apache or dhcpd) refuse to run.

[Diego Biurrun (diego-biurrun)]

On Wed, Jan 05, 2011 at 12:17:50PM +0000, Miika Komu wrote:
> Or maybe a -d as in configuration directory.
>
> What happens if no configuration is not found? For example, if I just
> download the sources and start hipd in the source tree?

hipd refuses to run without configuration file. Not much software is
expected to run straight from the place where it was compiled.

Diego

[Miika Komu (miika-iki)]

Built-in defaults sound nice but we don't have that luxury in HIP (there shouldn't be any default private keys, right?). So refusing to run is the only option but this sucks from the view point of usability. Nobody wants to copy files based on templates or whatever, and this is why hipd currently creates all necessary configuration files on first run. Another reason why hipd creates them is because we have currently four different ways to use hipd (directly from sources, make install, .deb and .rpm) and the current method just worked with all of them.

"make install" should probably create the necessary configuration files but not all people want to install (before trying out). So at least there should be "hipconf createconfigs" at the very least (*). Hipd/hipfw failing to start due to missing configs should instruct the user to run the command.

(*) It shouldn't be too difficult to move this functionality from hipd/init.c to hipconf.

[Miika Komu (miika-iki)]

If you choose change the established practice (a trade off between "purity" and "usability"), please remember to document this clearly to the manual and note on the users mailing list as well. Three developers (including me) have had troubles with the /usr/local/etc change even though we knew about the change :)

[Stefan Götz (stefan.goetz-deactivatedaccount)]

I'm skeptical of this 'running from source' business. From my experience, many tools built with the GNU tool chain do require a 'make install' invocation for precisely the reasons discussed here. Personally, I would, in this case, rather go with what other projects do and people are used to anyway instead of having a custom solution with the only convenience of saving one the trouble of calling 'make install' (and maybe giving a custom --prefix option to configure). Just my two pence.

[Diego Biurrun (diego-biurrun)]

On Wed, Jan 05, 2011 at 01:59:28PM +0000, Stefan Götz wrote:
> I'm skeptical of this 'running from source' business. From my
> experience, many tools built with the GNU tool chain do require a 'make
> install' invocation for precisely the reasons discussed here.

+1

Please don't extrapolate from your own experience to common practice.
Just think of the /usr/local/etc issue. This is the standard path for
self-compiled software on Unix. You were only accustomed to something
due to years of broken defaults in HIPL.

Diego