[Sks-devel] Debian asks package and default paths

[Hendrik Visage]

Good day,

Busy setting up a SKS keyserver, and wants to have a separate /sks filesystem, and before I start to add symlinks
all over the place, or re-compile SKS, I was wondering how/where to override the defaults in the configuration files.

I’ve already set base_dir: /sks2/sks/db, but then I still get this:
Fatal error: exception Sys_error("/sks2/sks/db//var/log/sks/db.log: No such file or directory”)

strings does show that /var/log/sks/db.log is in the Debian packaged /usr/sbin/sks file.

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
[phone] or [phone]
***@envisage.co.za

[Alain Wolf]

Hey

Post by Hendrik Visage
Good day,
 Busy setting up a SKS keyserver, and wants to have a separate /sks
filesystem, and before I start to add symlinks
all over the place, or re-compile SKS, I was wondering how/where to
override the defaults in the configuration files.
Fatal error: exception Sys_error("/sks2/sks/db//var/log/sks/db.log: No
such file or directory”)
strings does show that /var/log/sks/db.log is in the Debian packaged /usr/sbin/sks file.

I would try to change desired filepaths in
debian/patches/0001-use-debian-fhs.patch

[Hendrik Visage]

Post by Alain Wolf

Post by Hendrik Visage
strings does show that /var/log/sks/db.log is in the Debian packaged /usr/sbin/sks file.

I would try to change desired filepaths in
debian/patches/0001-use-debian-fhs.patch

Okay, that implies recompiling/packaging ;)

Thanks!

[Daniel Kahn Gillmor]

Post by Alain Wolf
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)

b) enables running multiple keyservers on a given host

c) people can upgrade their existing installations without too much
pain

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.

Anyway, i'm just saying that just because it's this way today, it
doesn't have to be this way forever. feedback welcome :)

--dkg

[Hendrik Visage]

Thanks for the explanation Daniel

Post by Daniel Kahn Gillmor

Post by Alain Wolf
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
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)

Post by Daniel Kahn Gillmor
b) enables running multiple keyservers on a given host

That is what base_dir: is suppose to achieve, isn’t it?

Post by Daniel Kahn Gillmor
c) people can upgrade their existing installations without too much
pain

Yes, that’s the part that always becomes a problem in special setups...

Post by Daniel Kahn Gillmor
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.

Post by Daniel Kahn Gillmor
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.

[Martin Dobrev]

Hi,

my 2 dimes in-line too

Post by Hendrik Visage
Thanks for the explanation Daniel

Post by Daniel Kahn Gillmor

Post by Alain Wolf
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
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)

Post by Daniel Kahn Gillmor
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)

Post by Hendrik Visage

Post by Daniel Kahn Gillmor
c) people can upgrade their existing installations without too much
pain

Yes, that’s the part that always becomes a problem in special setups...

Post by Daniel Kahn Gillmor
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.

Post by Daniel Kahn Gillmor
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
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Alain Wolf]

Post by Daniel Kahn Gillmor

Post by Alain Wolf
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

The only proposal that comes to my mind is to 'fix' this within SKS
itself by adding command-line options and or config-file options.
Apparently there is already ticket:

https://bitbucket.org/skskeyserver/sks-keyserver/issues/6/make-directories-better-configurable

Multiple instances could then be setup like .i.e. Tor with
tor-instance-create(8).

But sorry, I am again in no position to help there.

[dirk astrath]

Hello,

To run a sks-server accessible via TOR and normal usage don't require to
run different instances.

A usage, which comes to my mind is to run keyservers for different purposes:

#1 as a normal keyserver for the keyservers pool.
#2 as a special keyserver for a keysigning-party/...

(of course: in this case you need different IP-adresses for both servers
;-) )

Kind regards,

dirk

Post by Alain Wolf

Post by Daniel Kahn Gillmor

Post by Alain Wolf
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

The only proposal that comes to my mind is to 'fix' this within SKS
itself by adding command-line options and or config-file options.
https://bitbucket.org/skskeyserver/sks-keyserver/issues/6/make-directories-better-configurable
Multiple instances could then be setup like .i.e. Tor with
tor-instance-create(8).
But sorry, I am again in no position to help there.
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel

[James Cloos]

HV> I’ve already set base_dir: /sks2/sks/db, but then I still get this:
HV> Fatal error: exception Sys_error("/sks2/sks/db//var/log/sks/db.log: No such file or directory”)

Wouldn't it be easier to just mount your extra disk at /var/lib/sks?

/etc/sks is tiny and /var/log/sks is also reasonably small.

Only /var/lib/sks is large and under heavy load.

You could use a symlink from /var/log/sks to /var/lib/sks/log to get the
logs also onto your extra disk, but I wouldn't bother.

-JimC