SP packaging

[Russ Allbery]

"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,

Just for the record, no good syslog system should have this problem.  How
to configure it to avoid this varies, but generally there's some sort of
local queue and fallback behavior and it's all handled by the local
daemon without blocking the program unless the administrator specifically
configures it to be blocking (rare, and usually for some reason).

Also, note that old, traditional UNIX syslog also doesn't have this
problem for a different reason: originally, the remote syslog protocol was
UDP-only, so it was totally "fire and forget."  No way to block on remote
logging when you're just spewing out packets and never expecting a reply.

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

Yeah, this is a good point.  The stuff in there isn't often all that
useful.

> 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.

Yeah, that might work.  It means that you have to encode the user that
shibd is supposed to run as in a configuration file or something, but
that's maybe not too bad.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>