5 Čec
2012
5 Čec
'12
13:14
On 6/28/12 7:27 PM, Marek Vavruša wrote:
On 25 June 2012 21:37, Tom Hendrikx
<tom(a)whyscream.net> wrote:
I have 1.0.6 running with this patch for a few days now, and am not
seeing any issues with it. Thanks, feel free to include in 1.0.7 :)
--
Tom
On 20-06-12 18:58, Marek Vavruša wrote:
That's actually true, sorry for that, I have fixed that now, so only
zone compilation processes
ownership is modified. It's in a latest git, but again a patch against
1.0.6 is included (at least the main bits).
Or try the latest git branch 'development'.
Hi Tom,
so I have finally addressed the issue. Well, here are the changes:
- uid/gid is now changed only after startup (instead of each
configuration reload)
- PID file and others are created under correct configured user
(config key 'user myuser.mygroup')
- knotc now respects configuration (so zones are compiled under configured user)
- corrected log messages to be more helpful
- knotd now checks if 'storage' is writable and let's you know if it
isn't
So to run knotd as 'knot.knot' you have to make sure that the
'storage' directory exists and is writable by that user (
'/var/lib/knot' in your case). You can change 'storage' or
'pidfile'
path in the config, but still have to make sure the 'knot.knot' can
write to those. This should work even without the patch, so give it a
shot and let me know.
I just gave your patch some testing against 1.0.6, but it doesn't work
as expected. Main problem is that the unprivileged user cannot bind to
the privileged port (53). Reviewing the code, it looks like privileges
are dropped in the knotc utility, before starting the server process
itself.
I also tried with high port numbers (f.i. 5353) and that does works
without any issues.