Hi Christian! First off, thanks for the very detailed and constructive bug report! For future bug reports, please note that it's helpful to keep each issue in a separate bug report that can be responded to and fixed independently -- even if that means more bug reports for me to deal with! :)
On Tue, Aug 22, 2017 at 07:04:18AM +0000, Christian Strauf wrote: > (1) There seems to be a flaw in some versions of systemd which > concerns PID files. If a PID file of a service is manipulated (e. g. > to contain the value "1"), stopping the service will kill the process > whose process ID has been added to the PID file. To circumvent this > you can omit writing a PID file if the daemon allows it. radsecproxy > is simple enough so that systemd knows the PID after starting it, so > not writing a PID file isn't a problem in this case. This is what I'd > suggest for this package. The patch is included in the patch suggested > for issue (2). This sounds like a bug in systemd and should probably be addressed there. Do you know which versions are affected and/or do have a reference to that flaw? As far as radsecproxy's unit goes, I think actually the right solution would be to avoid daemonization altogether and switch to Type=simple. I've experimented with that, but unfortunately, there are some nasty side effects with radsecproxy's -f (foreground) option with regards to logging. I've already raised that with Linus (upstream), as the first step. > (2) Right now, radsecproxy is running as root. I'd like to propose the > following patch so that it's run a an unprivileged user "radsecproxy": That's a good point! I don't know how I've missed this. I'll have a look at doing this in the next upload. > (3) This issue is more a question than a bug report or suggestion. > Right now the control file has the dependency "debhelper (>= 10)". Is > this a hard dependency? If not, can it be changed to "debhelper (>= > 9)" again? There are various changes between debhelper 9 and 10 (e.g. running autoreconf by default). In general, there is little downsides with following the latest debhelper version and I prefer doing that. If your goal is to build a backport for an older Debian version, you can either downgrade the dependency in your backport yourself, or even better, just install debhelper 10, a build-time only dependency, in your older system. 10.2.5 is available in jessie-backports, precisely because a lot of newer packages need newer version of debhelper. > Thanks again for providing this package, it's highly appreciated! You're very welcome! Best, Faidon
