SP packaging

[Ferenc Wágner]

"Cantor, Scott" <cantor.2 at osu.edu> writes:

>> Could you elaborate a little?  What kind a logging do you mean, and what
>> are your reservations against syslog?
>
> Remote syslog in general makes me nervous when an application is
> potentially impacted by some kind of unrelated network issue, and I'm
> not familiar with any of the syslog system call code or safeguards
> against that happening,

It's very true that even local syslog can block if the syslog daemon
stalls for some reason.  And remote syslog can have plenty more reasons
to block.  You can't do anything about this within the standard syslog
API, but there are various solutions available.  One is tricking your
application into using UDP (https://github.com/facebook/liblogfaf),
another is running very reliable local Unix-to-UDP translation process
before syslogd, and finally, modern syslog daemons may be able to drop
undeliverable incoming messages to avoid blocking their clients.

> but by "this type of logging" I meant trace logging primarily used for
> debugging set up, which particularly describes native.log.

Agreed, trace or debug logging usually does not belong to syslog.  On
the other hand, it's critically important to be lossless, even if it
means affecting application timing.

>>> I think that's really a bug at this point, the -t option long predates
>>> use of an alternate user account.
>> 
>> SSPCPP-645 is closed, even though it has addressed the problem only
>> under SysV init, not under systemd.  Shell I open a new issue for this?
>
> Actually, what I was thinking was more along the lines of fixing shibd
> to setuid properly even when that option is used, but I haven't
> investigated why I might not have.

Probably because this function is not present in shibd: the uid change
is happening in the init script or in systemd, before shibd itself is
started.  So the first step should be accomodating these new
configuration items in the config file, then coding the uid change so
that it affects all code paths, and does not fail if the change has
already been made.

> I don't know if I know how to fix the startup thing under systemd, but
> I can take a look, or you can tell me how. A new issue is fine.

Well, there is ExecStartPre, which could serve as a workaround until
shibd can change uid on its own (if that takes long).  By the way, do
you plan to add socket activation support?  The current unit
dependencies need changing under Debian (apache vs. httpd, and see also
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/), so
there are several reasons for pushing it here.  Maybe for doing
something, even. :)
-- 
Regards,
Feri.