Thanks for the explanation Daniel
On 23 Jan. 2018, at 18:18 , Daniel Kahn Gillmor <address@hidden> wrote:
On Tue 2018-01-23 10:51:54 +0100, Alain Wolf wrote:
I would try to change desired filepaths in
debian/patches/0001-use-debian-fhs.patch
Hi there--
I'm one of the current maintainers of the debian package.
this patch is intended to put sks in compliance with the filesystem
hierarchy.
however, i'm not convinced that the patches in the debian package are
the right thing for debian today, since they basically hardcode a single
path (and make it difficult to run two instances of sks on the same
machine, for example). I'd welcome any proposals people have that:
a) retain the default filesystem placement to stay in line with the
filesystem hierarchy standard (FHS)
Well… FHS makes sense…. up to the point that I’m deploying each service in
it’s own set of mountpoints (ala old-style unix when disks was small, like in VMs
today with OS disk separate from the data disks)
b) enables running multiple keyservers on a given host
That is what base_dir: is suppose to achieve, isn’t it?
The only bit that's required is a configuration switch passed to the
daemon with the location of the configuration file. The rest (things
like base_dir etc.) is already covered inside it. I'd guess a
default value of /etc/sks/sksconf or similar will do the trick if
the parameter is omitted yet allows multiple instances on the same
box (although I don't see a point in doing so because if the server
dies all instances will be lost)
c) people can upgrade their existing installations without too much
pain
Yes, that’s the part that always becomes a problem in special setups...
d) (optional) can be merged upstream so that we don't carry patches :)
If i had more time, i'd experiment with dropping the patch completely,
and setting up a symlink approach in /etc/sks/ but i'm not sure whether
that would work; or if it works, if it would horrify anyone.
I’d personally rather prefer a configuration file/settings I could modify/tweak
w.r.t. those files/etc., then it’ll be much easier to have multiple SKS services on the
same server/VM.
Anyway, i'm just saying that just because it's this way today, it
doesn't have to be this way forever. feedback welcome :)
As it’ll be a recompile/repackage to achieve my goals (other than symlinks all over the show)
I’ll have a look as see what I can contribute back.
_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc