Re: configure path name of ebtables executable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 11/17/21 4:52 PM, Michael Ströder wrote:
On 11/17/21 20:28, Laine Stump wrote:
On 11/17/21 1:39 PM, Michael Ströder wrote:
Is it possible to configure the full path name of the ebtables executable used somewhere in libvirt's config?

That's done in when you're building from source. Look for "optional_programs".

Noted. Thanks.

Background: I'd like to avoid automatic alternatives implementation to mess up libvirt installation.

See also:

I don't think the problem is what is being suggested in that bug.

Yes, it is.

The suggestion in that bug is that the problem is because "libvirt need /sbin/ebtables point to ebtables-legacy", which is definitely not the case. libvirt only requires that /sbin/ebtables point to a binary that correctly understands and acts on any valid ebtables command. If the binary pointed to by /sbin/ebtables doesn't do that, then it shouldn't be pointed to by /sbin/ebtables.

follow the symlink from /sbin/ebtables to (probably)
/etc/alternatives/ebtables > [..]
This sounds more like SUSE has some sort of special off-brand
alternative that doesn't understand all valid ebtables commands
openSUSE Tumbleweed now uses libalternatives for ebtables (see my comment#2) and thus /sbin/ebtables was linked to /usr/bin/alts. Yes, something's broken there and I was looking for a work-around.

Anyway, I think you'd be better off fixing the problem at the source
rather than trying to make some special local build of libvirt to
work around the problem.
IMHO a libvirtd.conf option would be great to avoid relying on this alternatives stuff.

There are many things within libvirt that we could do ourselves in order to avoid relying on some other package (or add a config knob to point at something different to do the work), but that just makes more code that must be maintained forever. Working around bugs in other packages with package-local fixes and config knobs is a never-ending unwinnable battle once you start, and leads to unnecessarily complicated code and technical debt (I say this from painful experience - although it's a bit of a whatabout-ism, if I had the time (I unfortunately don't :-)) I would tell the story of iptablesAddOutputFixUdpChecksum, just as one example).

I think a better road in this case (and most other cases) would be to fix the package that is broken (sounds like libalternatives). If it is breaking libvirt, it's likely breaking other things as well.

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux