SP packaging

[Ferenc Wágner]

Russ Allbery <rra at debian.org> writes:

> wferi at niif.hu (Ferenc Wágner) writes:
>
>> One of the less obvious changes is changing back native.logger from
>> syslog to direct file writes.  If all configurations follow this,
>> libapache2-mod-shib2.logcheck.ignore.server could be dropped.  Should we
>> do this now or later or at all?
>
> What was the thought process here?  The changelog doesn't really say.

Hmm, indeed, you provided much more verbose entries.  The relevant ones
from 2.5.1+dfsg-1:

  * New upstream release.  (Closes: #685069)
    - The native.log file is now created as root before Apache child
      initialization to minimize permission issues.
  * Update libapache2-mod-shib2's README.Debian:
    - The reason for switching native.logger to syslog is now obsolete
      (but the package still does that, possibly to be reconsidered
      later).

The full commit message of a6ccea4 tells the other half of the story:

  Reset native.logger (Apache module logs) to upstream behavior

  Before 2.5.4 the upstream default was writing them into the Apache log
  directory.  As Apache couldn't create files there after dropping privileges,
  the internal log rotation did not work, thus we diverted those to syslog.

  Upstream recognized the problem and switched to using a separate package
  specific directory.  We've got no reason to deviate anymore.

  See also https://issues.shibboleth.net/jira/browse/SSPCPP-646.

As the linked issue shows, the upstream fix in 2.5.1 was partial only,
because the first file on Apache startup was indeed created as root, but
the following ones were not, so rotation did not work in the end.  This
is all fixed by using a private directory owned by www-data (btw. should
we change the group as well?)

> I made this change originally because the upstream behavior at the time
> didn't actually work.  As in you would not get anything written to the
> static file because Apache didn't have permission to write to it.  There's
> probably some way to fix that up in postinst, etc., or maybe upstream came
> up with some fix a long time ago and I never noticed?

www-data is a static user, we can simply ship a directory owned by it.

> As long as it works, I have no opinion, as I'm not currently using
> Shibboleth and there is definite merit in following upstream behavior.

Basically, that was my reason for the change: easier upstream support.

> I will say that when I was running Shibboleth myself, I had Strong
> Feelings about this behavior, namely that logging things directly to a
> file is extremely irritating behavior: it breaks local log rotation
> (we didn't use logrotate), it separates the logs from everything else
> and thus from the normal log analysis flow, it means any syslog
> aggregation system requires special work to deal with local files, it
> makes it harder to get the logs into systems like Splunk or an ELK
> stack, etc.

Fully agreed.  I kept the logcheck file partly to make it easy for the
admin to change logging configuration to syslog.

> But I no longer have strong feelings since I'm not currently using it,
> so I'm happy to have someone else change it to something they have
> Strong Feelings about.  :) Just wanted to be sure that you knew the
> original reasons why this was done.

Thanks.  No strong feelings here, just practical matters.  So I'm not
decided, opinions welcome from everybody!

>> Also, according to https://issues.shibboleth.net/jira/browse/SSPCPP-645,
>> running shibd -t as root can cause permission problems.  I don't think
>> we handle this either in the init script or in the service file.
>> Something to check...
>
> The init script (I assume that's what you're looking at) tries to run it
> as _shibd, and only falls back on using root if that fails.  This was
> because the local keys might not be readable by _shibd because _shibd was
> a later innovation in the Debian packages and I didn't have a good
> migration strategy.  It's been years and years now, so maybe it would be a
> good idea to just put something in NEWS.Debian and only use _shibd and let
> the init script fail if that doesn't work.  The systemd unit file already
> does that.

I'm thrilled to remove this fallback from the init script.  But the
above mentioned problem is largely unrelated.  The issue is that the
admin can naturally issue shibd -t to check the config after some
modification, and if this test run creates new metadata files (for
example) in /var/cache/shibboleth, those will we owned by root.  Thus
the daemon running as _shibd can't update them later.  I can't see a way
to fix cleanly without putting the identity change into shibd.
-- 
Thanks,
Feri.