Moritz Wilhelmy <ml+pkgsrc%wzff.de@localhost> writes:
> On Mon, Aug 06, 2012 at 18:13:18 -0400, Matthew Mondor wrote:
>> On Mon, 06 Aug 2012 14:22:47 -0400 Greg Troxel <gdt%ir.bbn.com@localhost>
>> wrote:
>> > It sounds like iodine needs a config file to get this from, but that's
>> > an upstream bug.
>
> Well, it works fine the way it does, so I'd say it doesn't need anything
> per se...
Interactively reading a password and not having an option to read it
From a config file is a bug, even if it doesn't annoy you in particular...
>> Considering that its not rare for distributions to provide config files
>> for tools, it would also be possible to provide example configuration
>> file(s) in files/ and to install it/them under examples/ at
>> post-install, i.e.:
>>
>> INSTALLATION_DIRS+=share/examples/iodine
>>
>> post-install:
>> ${INSTALL_DATA} ${FILESDIR}/foo.conf
>> ${DESTDIR}${PREFIX}/share/examples/iodine/foo.conf
>>
>> (of course these then also should be in PLIST)
>>
>> It's also possible to then decide that one/some of the example(s)
>> should also be copied as necessary to a configuration directory (if the
>> user has custom modifications, these won't get deleted by pkg_delete or
>> overwritten by pkg_add):
>>
>> CONF_FILES+=${PREFIX}/share/examples/iodine/foo.conf
>> ${PKG_SYSCONFDIR}/foo.conf
>>
>> If we do such, I'm not saying that we shoudn't recommend to the
>> upstream maintainer to also include those as part of the iodine
>> distribution in the future :)
>
> I'd rather not include a custom config file, i.e. one not understood by
> upstream iodine. After all, this isn't debian. That is, I don't want to
> assemble command line options to iodine by reading a custom conf.d
> hierarchy and assembling it. I also hate it when the configuration
> procedure deviates from what's documented by upstream. However, I assume
> this isn't what you're proposing.
>
> iodine/iodined comes completely without a config file. Options are read
> entirely through command line. Upstream told me my assumption about the
> password being readable to anyone with access to ps(1) was wrong
> (because apparently they overwrite the proctitle), so I assume there
That's probably os-dependent.
> isn't much in the way of just using them from within the rc script.
> Including an rc-script would indeed simplify starting and restarting
> iodine; I will supply one that reads a simple string of arguments from
> rc.conf and applies them when starting iodine(d).
>
> Please complain if you have a better idea.
That sounds like exactly the right thing. Really iodine should be able
to not have command-line args and instead read /usr/pkg/etc/iodine.conf,
including password, but that's not a great thing for pkgsrc to get into
changing. (I view iodine as not really different from aiccu.)
Attachment:
pgpKdHK4iSNZ_.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ pkgsrc-wip-review mailing list pkgsrc-wip-review%lists.sourceforge.net@localhost https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review