managing `innd' to read `inn.conf' from an alternative location

[Ivan Shmakov]

>>>>> Jeffrey M Vinocur <jeff at litech.org> writes:

 >>> You could run two installations of INN

 >> IIUC, in the latter case, I'd need to prepare a separate `inn.conf'
 >> for the second copy of `innd', roughly with most of the `path*'
 >> parameters pointing to different locations (so not to clash with the
 >> first copy of `innd'.)

 > I imagine you can't easily do this with the Debian package, but if
 > you compile from source, you can simply use the --prefix= flag with
 > ./configure and locate the whole INN tree somewhere else.

	Yes, I know.
 
 >> * is there support for overriding the compiled-in location of
 >> `inn.conf' for `innd' in any other (newer) version of INN?

 > You can't do this per se, because the paths are compiled into the
 > binaries.  So you'd need two separate copies of the whole package, as
 > above.

	Yes.  But, IIUC, the only path that cannot be overriden at the
	run time (at least, via an `inn.conf' option) is the path to the
	`inn.conf' file.

	... Or, wait, I've just checked the source...

--cut: inn2-2.4.3+20070806-debian-1/lib/innconf.c--
   426	/*
   427	**  Read in inn.conf.  Takes a single argument, which is either NULL to read
   428	**  the default configuration file or a path to an alternate configuration
   429	**  file to read.  Returns true if the file was read successfully and false
   430	**  otherwise.
   431	*/
   432	bool
   433	innconf_read(const char *path)
   434	{
   435	    struct config_group *group;
   436	    char *tmpdir;
   437	
   438	    if (innconf != NULL)
   439	        innconf_free(innconf);
   440	    if (path == NULL)
   441	        path = getenv("INNCONF");
   442	    group = config_parse_file(path == NULL ? _PATH_CONFIG : path);
--cut: inn2-2.4.3+20070806-debian-1/lib/innconf.c--

	Looks like the `inn.conf' location can be overriden!

 >> * what else may prevent me from running two copies of `innd' from
 >> the one installation?

 > The other thing that may be tricky is the allocation of ports.
 > Obviously both copies will not be able to listen on port 119 of the
 > same IP address.  If you're comfortable playing with linux networking
 > type stuff I'm sure you can think of a variety of approaches to this
 > issue...

	ACK.  Thanks.