Quoting Guilhem Moulin (2020-04-05 02:54:46) > Control: severity -1 wishlist > > Hi Jonas, > > On Sat, 04 Apr 2020 at 20:56:50 +0200, Jonas Smedegaard wrote: > > lacme supports being remote-controlled from an external host _almost_ > > out-of-the-box. > > However it supports being locally controlled out of the box :-) This is > a deliberate tradeoff: I wrote lacme because I didn't want the account > key to live next to the server key, but local account keys are still a > valid use-case for lacme IMHO thanks to its multi-process architecture > and privilege dropping. > > > If only [accountd] section header was commented out by default > > (none of the items within that section are explicitly enabled anyway), > > The presence of the [accountd] section header indicates that lacme(1) > should fork a local lacme-accountd process instead of connecting to a > socket. I'm reluctant to replace that configuration check with checking > whether the sockets exists and can be connected to, because that would > mean a local lacme-accountd process would be forked when one forgets to > forward the socket or start the remote process. > > > it is possible to use lacme with a remote accountd _without_ touching > > any conffile. > > I see the appeal in that, will think of a better detection logic; > Suggestions welcome :-)
How about respecting "lacme --socket=path" - it is common behaviour for command-line options to take priority over configfile options, and you've swapped that logic for lacme making configfile editing mandatory. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
