On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote: >> I don't know whether this should be a gnome-boxes bug, an rpcbind bug, >> or a FESCo ticket, or something else, so I'm asking here. >> >> rpcbind enables itself by default. This page says that it has a >> specific exception, so it's okay: >> >> https://fedoraproject.org/wiki/Starting_services_by_default >> >> I assume that the exception comes from the idea that server systems >> probably want it on if they've installed it. That may make sense in >> some contexts. >> >> Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which >> requires nfs-utils, and nfs-utils requires rpcbind. >> >> gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this: >> >> tcp 0 0 0.0.0.0:111 0.0.0.0:* >> LISTEN 774/rpcbind >> tcp 0 0 0.0.0.0:20048 0.0.0.0:* >> LISTEN 887/rpc.mountd >> tcp 0 0 0.0.0.0:875 0.0.0.0:* >> LISTEN 930/rpc.rquotad >> >> *on my laptop* >> >> IMO this is bad. Should I file a FESCo ticket asking to revoke the >> rpcbind and nfs-utils exceptions? Should I file a bug against >> libvirt? > > Shouldn't rpcbind be simply a dependency for > nfs-server.service/nfs-secure-server.service and be started only if the > nfs server is started ? > rpcbind has this script: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Initial installation /bin/systemctl enable rpcbind.service >/dev/null 2>&1 || : fi nfs-utils has this script (excerpted): postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ]; then # Package install, /bin/systemctl enable nfs.target >/dev/null 2>&1 || : /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || : /bin/systemctl start nfs-lock.service >/dev/null 2>&1 || : nfs-utils is also pulled in by libvirt. Why is nfs special enough to deserve this kind of automatic enablement? I would argue that nfs requires so much manual configuration in order to do anything useful that requiring admins to turn it on would be just fine. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
