On Thu 2016-05-12 09:43:12 -0400, Christoph Anton Mitterer wrote:
> btw: It seems that -8, (in which sks starts again), the service is not
> enabled per default.
>
> I personally think that's good, because I consider Debian's usual
> behaviour of enabling services at installation insecure and stupi
On Thu 2016-05-12 09:00:30 -0400, Christoph Anton Mitterer wrote:
> I've had seen that, but as I wrote in my mail before, it may actually
> not even be required (and my original request would thus be wrong).
sks definitely needs access to the local filesystem (/var/lib/sks) and
to the network (it
On Wed, 2016-05-18 at 11:32 -0400, Daniel Kahn Gillmor wrote:
> the sysvinit approach also doesn't start the service by default. the
> admin has to manually edit /etc/default/sks in order to get it to
> start
> up.
Well sure, but that's just something that some services offer, and it
kinda conntra
Package: sks
Version: 1.1.5-5
Severity: important
Hi.
As for the systemd unit files:
1) Almost for sure, they miss quite some dependencies,
at least things like network.target and perhaps
something that makes sure the local fs is there?
2) Right now sks.service wants sks-recon.service, but
Oh and I forgot:
>BindTo=sks.serviceYou probably mean BindsTo, BindTo, AFAICS doesn't exist.
smime.p7s
Description: S/MIME cryptographic signature
Hi Daniel.
I've seen commit eff25289e1244ac74ecae5a1a1c04113e052a27c ...
On Sun, 2016-05-08 at 23:14 +0200, Christoph Anton Mitterer wrote:
> 1) Almost for sure, they miss quite some dependencies,
> at least things like network.target and perhaps
> something that makes sure the local fs is
Hi Christoph--
thanks for these thoughtful notes, and for your prompt testing of sks
1.1.5-5. 1.1.5-7 should address these concerns (and several others) but
i wanted to comment a little here too:
On Sun 2016-05-08 17:14:35 -0400, Christoph Anton Mitterer wrote:
> 1) Almost for sure, they miss qu
On Thu, 2016-05-12 at 02:13 -0400, Daniel Kahn Gillmor wrote:
> This is now handled by having the following line in the Unit section
> of
> /lib/systemd/system/sks.service:
>
> After=local-fs.target network.target
I've had seen that, but as I wrote in my mail before, it may actually
not even be
btw: It seems that -8, (in which sks starts again), the service is not
enabled per default.
I personally think that's good, because I consider Debian's usual
behaviour of enabling services at installation insecure and stupid, but
perhaps you may still want to follow that.
Cheers,
Chris.
smime.p
9 matches
Mail list logo