Bug 647831

100% reproduceable with

kernel-2.6.36.1-10.fc15.x86_64
avahi-0.6.28-3.fc15.x86_64
selinux-policy-3.9.10-4.fc15.noarch

Problem still exists:

kernel-2.6.38-0.rc3.git0.1.fc15.x86_64
avahi-0.6.28-7.fc15.x86_64
selinux-policy-targeted-3.9.13-8.fc15.noarch

ccing dwalsh for possible selinux policy involvement

john could you look for AVC messages in dmesg?

dmesg | audit2allow

Nothing in Matej messages indicates an SELinux issue with avahi.  Can either you boot in permissive mode and see if it starts?

I also don't think this is an SELinux issue. Problem seems to lie in broken /sbin/chkconfig in case both /etc/init.d/ script and systemd services are present. Then chkconfig works with init.d script, but systemd uses .service file. So, when some maintainer leaves in package both init.d script and .service file chkconfig seems like working, but actually it has no effect on functioninig of the system.

I think the priorities should be other way around ... whatever subsequent run of systemd will be actually used should be changed by chkconfig, or at least chkconfig should provide big fat warning. Something like "changing running of sysvinit script, but .service file is also present" or something.

Re: Comment 5


    [root@fc15-64 ~]# dmesg | audit2allow


    #============= vbetool_t ==============
    #!!!! This avc can be allowed using the boolean 'mmap_low_allowed'

    allow vbetool_t self:memprotect mmap_zero;
    [root@fc15-64 ~]# 



Changong to permissive mode did not fix anything.

So this is not an SELinux issue.  John you might want to remove vbetool and see if everything works (suspend/resume).  You probably do not need this package.

I removed vbetool, thanks.  (Didn't have any effect on the avahi-daemon bug.)

Assuming Matej is on the right track, should I be using something other than chkconfig to start the service?   Should I be removing sysvinit ?

My fedora-15 and fedora-16 systems are all from upgraded fedora-14 systems, so do I have some residual junk that I need to get rid of?   Is there some doc I need to read so as to not waste your valuable time?

(I don't really care about the innards of systemd, I just want updated sys-admin instructions if I'm supposed to do something new.)

Normally, when the Avahi package got upgraded from a sysv-only to a systemd version it should have copied over whether the old init script was enabled or not.

Hmm, one question: did this break during upgrade, or is this simply something where you expected "chkconfig avahi-daemon on" to work but it had no effect?

Note that "systemctl enable avahi-daemon.service" is how you enable systemd native services.

Bill recently commited some changes I made to chkconfig to forward enabling requests to "systemctl enable". If this is not a problem related to upgrading than this fix should fix the problem.

I created the virtual host images by:
    1. installing fc14
    2. changing the settings in etc/yum.respo.d/* to enable rawhide and disable fedora and updates.
    3. doing a "yum update"

As I recall, avahi-daemon was not enabled before, and is not enabled by default in rawhide, so i think I enabled it after upgrading to rawhide by using "chkconfig'

So, as I understand it, I was correct in expecting "chkconfig" to work, but it wasn't ? 


I don't see the chkconfig update yet, but I can confirm that "systemctl enable avahi-daemon.service" followed by a reboot has fixed the problem.

Fedora 15 Alpha installs are starting with avahi disabled:
# systemctl status avahi-daemon.service
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
	  Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/avahi-daemon.service
# systemctl is-enabled avahi-daemon.service || echo avahi disabled
avahi disabled


F14 avahi %post does:
# Run avahi-daemon by default:
  /sbin/chkconfig --add avahi-daemon >/dev/null 2>&1 || :
  /usr/bin/systemd-install --realize=minimal enable avahi-daemon.service >/dev/null 2>&1 || :

F15 avahi %post does just:
  /sbin/chkconfig --add avahi-daemon >/dev/null 2>&1 || :

chkconfig only touches systemd if you give it 'on' or 'off', so I think you need to add:
  /sbin/chkconfig avahi-daemon on >/dev/null 2>&1 || :

if we still want the service to be on-by-default. Or maybe there's some magic LSB header parsing in systemd that's not working right?

The service is no longer on by default, as it is open to the network. If we want it enabled by default we probably should do so in some script after installation.

(In reply to comment #13)
> The service is no longer on by default, as it is open to the network. If we
> want it enabled by default we probably should do so in some script after
> installation.

Except it kind of defeats the purpose of Avahi, doesn't it? Do we expect your mom (or dad to be PC ;)) to like that he has to run su -c 'chkconfig avahi-daemon on' ?

I don't want my Dad running avahi.  :^)

(In reply to comment #14)
> (In reply to comment #13)
> > The service is no longer on by default, as it is open to the network. If we
> > want it enabled by default we probably should do so in some script after
> > installation.
> 
> Except it kind of defeats the purpose of Avahi, doesn't it? Do we expect your
> mom (or dad to be PC ;)) to like that he has to run su -c 'chkconfig
> avahi-daemon on' ?

No, but the installation program should have enabled it by default.

My dad runs Avahi! ;-)

Avahi is needed for network printer discovery.

It's also needed for telepathy-salut ("People Nearby" account) in Empathy which is created during account set-up.  Without avahi enabled the account throbber will continuously spin unless the salut account is disabled.

*** Bug 684498 has been marked as a duplicate of this bug. ***

Hmm, so, I'd like to see avahi enabled by anaconda or so, instead of in the rpm package itself. That way people who install fedora get it enabled by default, but those who install the package on an existing system don't. I think that behaviour would be best.

Reassigning to anaconda.

Anaconda folks, can you add a "systemctl enable avahi-daemon.service" call somewhere when installing Fedora to HDD?

(In reply to comment #20)
> Hmm, so, I'd like to see avahi enabled by anaconda or so, instead of in the rpm
> package itself. That way people who install fedora get it enabled by default,
> but those who install the package on an existing system don't. I think that
> behaviour would be best.
> 
> Reassigning to anaconda.
> 
> Anaconda folks, can you add a "systemctl enable avahi-daemon.service" call
> somewhere when installing Fedora to HDD?

From a user usability standpoint, it would be nice to also poke a hole in the firewall for port 5353 at the same time, so avahi support works out of the box.

Perhaps that's something that ought to be handled at run-time using firewalld?

(In reply to comment #22)
> Perhaps that's something that ought to be handled at run-time using firewalld?

Firewalld isn't installed by default is it? I think once it is, that would make sense.

I'd really like to avoid making the installer responsible for setting up the default services. I don't want to put that code outside the reach of the people packaging the services, and I *really* don't want the installer team to be politically responsible for the decision to enable or disable a service.

What about this: it's possible that a package's %post script could detect whether it's being run during initial system install. In that case, you could have avahi enable itself *only* during system instalation - it could even run 'lokkit --service=mdns' to properly configure the firewall for avahi (open port 5353 and enable v4/v6 multicast). Would that work?

(I personally want avahi on/enabled by default, but I understand that there are plenty of people who would vehemently disagree, and for not-wholly-unsound reasons.)

As a side note: systemd won't be running during installation, so I'm not sure if doing 'systemctl enable ..' in anaconda would even work. It might make sense to have a kickstart 'systemctl' command which would correctly enable/disable services on the target system - but that's a different bug entirely, and it still wouldn't actually solve the problem here.

(In reply to comment #22)
> Perhaps that's something that ought to be handled at run-time using firewalld?

firewalld for normal users is a F16 Feature.

*** Bug 689859 has been marked as a duplicate of this bug. ***

(In reply to comment #24)
> I'd really like to avoid making the installer responsible for setting up the
> default services. I don't want to put that code outside the reach of the people
> packaging the services, and I *really* don't want the installer team to be
> politically responsible for the decision to enable or disable a service.
> 
> What about this: it's possible that a package's %post script could detect
> whether it's being run during initial system install. In that case, you could
> have avahi enable itself *only* during system instalation - it could even run
> 'lokkit --service=mdns' to properly configure the firewall for avahi (open port
> 5353 and enable v4/v6 multicast). Would that work?

How would we detect this?

I am not entirely sure this is really the ideal solution, as I think this should be in some installation profile thing, rather than in the packages. After all, on a desktop spin install we might want it installed and on, and on a server spin we might want it installed and off.

However, given that we apparently don't have such a profile thing, what you suggest is a workable solution.

> As a side note: systemd won't be running during installation, so I'm not sure
> if doing 'systemctl enable ..' in anaconda would even work. It might make sense
> to have a kickstart 'systemctl' command which would correctly enable/disable
> services on the target system - but that's a different bug entirely, and it
> still wouldn't actually solve the problem here.

"systemctl enable" detects when it is run in a chroot, and if so will never try to talk to systemd, and just enable the unit files in the FS and that's that.

So, if anaconda calls systemctl in a chroot things should be jolly.

*** Bug 693094 has been marked as a duplicate of this bug. ***

*** Bug 684754 has been marked as a duplicate of this bug. ***

I agree that installation profiles would be a really clean way to handle this type of thing. We should revisit that idea soon.

Martin Sivak had a really good idea: what if you created a package (something like 'fedora-profile-desktop') that had:

%post
systemctl enable avahi-daemon.service
lokkit ----service=mdns
[etc.]

and added that to the gnome-desktop comps group as a default package?

(For F16 and beyond: if we had profile packages like this for -server, -workstation, etc. we could easily put them in their own comps group, and present those in the anaconda UI. That would give us installation profiles, controlled outside the anaconda team. Hooray!)

Hmm, I am not sure I want to be the one championing this as that wouldn't be just a small change and probably requires more buyin from other people. But sounds like a really good idea for F16.

Hmm, in #24 you mentioned packages can detect if they are installed during system installation or later on. How would that work? That might be a quick fix suitable for F15.

(Only way I could think of would be to detect a chroot env, but that'd be a bit ugly)

There's no well-defined way to check whether you're in anaconda's chroot. You could do:
  [ `pidof -x anaconda` ] && ...
but I strongly discourage using that to solve this problem.

The Real Solution for opening the ports is firewalld, but that's not here yet.

The Real Solution for deciding which services etc. get enabled by default in a new install is probably system profiles. And the anaconda team seems to agree that system-profile (meta|speudo)packages are the best way to tackle this.

So I'd suggest creating a fedora-profile-desktop (or similar) package to handle this problem.. BUT. 

I just noticed this: 
https://fedoraproject.org/wiki/Starting_services_by_default

As of 23 March 2011 avahi is on the official FESCo list of services that may start by default.. so it's perfectly OK for avahi to enable itself and open the ports when it gets installed.

I will now upload a new version which enables avahi by default again.

This will enable avahi only for new installs. People upgrading from an existing F15 version need to enable it manually with "systemctl enable avahi-daemon.service"

avahi-0.6.30-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/avahi-0.6.30-2.fc15

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

*** Bug 701904 has been marked as a duplicate of this bug. ***

avahi-0.6.30-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

I still see this problem with 0.6.30-3.fc15. Could you reopen this bug?

did you do "su -c 'systemctl enable avahi-daemon.service'" after the upgrade?

RavanH: no I didn't, running that command seems to have fixed it. 

Should I also run such a command for other services (such as sshd and cherokee) that still don't start? Will users installing from the final release have to run this command?

as i understand it, an install from final should not need the command, just for those that installed previously to the fix... no idea about other services.