Bug 737060

this certainly seems to be the case, nothing in audit's scripts attempts to enable the service post install:

[root@adam adamw]# rpm -q --scripts audit
postinstall scriptlet (using /bin/sh):
if [ $1 -eq 1 ] ; then
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi
preuninstall scriptlet (using /bin/sh):
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
    /bin/systemctl try-restart auditd.service >/dev/null 2>&1 || :
fi
postuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
  /bin/systemctl --no-reload auditd.service > /dev/null 2>&1 || :
  /bin/systemctl stop auditd.service > /dev/null 2>&1 || :
fi

if it was enabled by default when it was a sysv service, this does look like a bug. CCing Viking.

It was definitely enabled by default before.

Assuming the scriplets here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd are correct, audit-2.1.3-3 should fix the problem.

audit-2.1.3-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/audit-2.1.3-3.fc16

Please test the new package and give it karma if works for you. 

Also, has anyone noticed if all the services that depend on audit have an After=auditd.service? This should include things like: setroubleshootd, crond, gdm, sshd, vsftpd, kdm, xdm, dbus, and nscd to name a few.

steve: that looks like it'll work for new installs, but as I read it, it'll be disabled on upgrades. Your %triggerun looks rather different from what's recommended on the page:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript

it's missing the systemd-sysv-convert block, and - as audit is "allowed to autostart" - the systemctl enable bit.

I have reservations about that triggerun, though...as I read it, if you install F15, manually disable an enabled-by-default service, then upgrade to F16, it'd be enabled again, as the packager, following that guide, would put a 'systemctl enable' in the %triggerun. Still, that's what it says.

Arguable auditd should have those listed in Before= line in it's unit file...

Package audit-2.1.3-3.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing audit-2.1.3-3.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/audit-2.1.3-3.fc16
then log in and leave karma (feedback).

So in 738803 we have a lot of people reporting that RC1 doesn't boot because of selinux issues...and those selinux issues don't appear in sealert. I assumed the only consequence of this bug would be alerts logging to /var/log/messages rather than /var/log/audit/audit.log , but is it more serious than that? If it is, this might be Beta NTH material...

Yeah, I think comment #9 is correct.

So, when I boot beta RC1 there's lots of alerts. Three of them, all relating to colord reading iCC profiles, seem to repeat each time you log out or log in, so they're useful tests.

nothing shows up in sealert, as mentioned. But if I do 'systemctl enable auditd.service', then log out and log back in, I do get sealert pop ups for those three alerts.

so it seems like you don't get SELinux alerts unless auditd is running; I think that's worth fixing for Beta.

especially since, with the current auditd package, I believe if we don't pull it into the Beta, the service won't get enabled on updates either.

follow-up to comment #6: just tested, and indeed, on an f15->f16 upgrade, auditd is not enabled.

I am submitting an update that fixes this, by adding the scriptlet bits from the wiki page that were missed in -3.

audit-2.1.3-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/audit-2.1.3-4.fc16

after installing audit-2.1.3-4, auditd is running and capturing SELinux denials again on a beta RC1 install

when you say 'installing' - did you upgrade to that build, or remove the package and do a 'fresh install'? either isn't actually a great test for this change, what we need to test is an upgrade from an audit build before 2.1.2-2, to audit 2.1.3-4. This should result in audit being enabled, whereas upgrading from a pre-2.1.2-2 build to 2.1.3-3 did not. 

(actually, if upgrading from anything between 2.1.2-2 and 2.1.3-3 to 2.1.3-4 results in auditd being enabled, I believe that's a bug - even though it's kinda good.)

Discussed at 2011-09-16 NTH review meeting. Accepted as NTH due to the impact - hides SELinux issues, which impairs proper Beta testing and fixing.

audit-2.1.3-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Pre-upgraded from F15 to F16. Audit service was running before upgrade and is not afterwards - verified by inspection of old and new /var/log/boot.log.

http://pkgs.fedoraproject.org/gitweb/?p=audit.git;a=commitdiff;h=b3b54c6117b1db38cf27df30bd6c128ad7b467bc has ' %triggerun -- audit  < 2.1.2-2' but F15 had audit-2.1.3-1.fc15.x86_64 installed.

steve: looks like the triggerun needs updating...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.