Hi Steve, On Sun, Feb 12, 2023 at 2:48 AM Steve Langasek <steve.langa...@ubuntu.com> wrote: > > Hi Andreas, > > On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote: > > Hi, > > > In the next few days, if all goes according to plan, I'll upload > > rsyslogd to lunar with a change[1] to the way its apparmor profile is > > applied. > > > The confinement status won't be changed during upgrades, but fresh > > installs will have the apparmor profile enforced by default. Up until > > now, it's been disabled. > > Can you elaborate on this decision not to change the behavior on upgrade? > It's expected on upgrade between releases that behavior will change; and to
Hmm, you are right, I was thinking in the context of lunar to lunar upgrades, and not release upgrades, which is what we are aiming for. > not enforce for upgrading users means a difference in configs between new > installs and upgrades that complicates the support matrix over the long > term. > > I am strongly in favor of making the behavior on upgrade conform to the > behavior on new installs - even if that means there might be some unpleasant > surprises where the package fails to configure because of apparmor being > enabled. That seems unlikely to me in any case; even if the user has > diverged from the stock rsyslog config, it seems more likely to me that the > daemon would still start up but might in some cases fail to log. Again, Correct, I'm not failing the startup because apparmor failed to apply or load, and that is in line with current rsyslog's behavior towards its plugins. If a plugin fails to write a log (like mysql is not available, or apparmor prevented it from doing so), it will just keep retrying in the background, instead of failing the whole daemon or the logging to other places. I'll make the change, thanks for the feedback! -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam