3. What is the nature and description of the request? the interface name that is used by RHEV/Ovirt is causing various problems with other software. ";vdsmdummy;" is not a sensible interface name. the ; characters has to specially escaped for bash and other tools. It would save a lot of hassle and work if ovirt would use sensible names. I don't see any reason to use special chars in the interfacename. The reason was to eliminate possible conflicts. This is not a real issue in my view. http://lists.ovirt.org/pipermail/users/2014-November/029392.html Examples: Facter: https://access.redhat.com/solutions/799413 https://tickets.puppetlabs.com/browse/FACT-546 spacewalk: https://bugzilla.redhat.com/show_bug.cgi?id=1011049 rkhunter rootkit hunter tool: + for FNAME in '${OPT_VALUE}' + test -z '/dev/.udev/db/net:;vdsmdummy;' ++ echo '/dev/.udev/db/net:;vdsmdummy;' ++ egrep '(^[./]*$)|[;&]|/\.\./' + '[' -n '/dev/.udev/db/net:;vdsmdummy;' ']' + ERRCODE=1 + echo 'Invalid ALLOWDEVFILE configuration option: Invalid pathname: /dev/.udev/db/net:;vdsmdummy;' 4. Why does the customer need this? (List the business requirements here) Prevention of problems with various tools. Creates additional work for debugging and workarounds. Could possibly have side effects as the ; is a command delimiter in bash. 5. How would the customer like to achieve this? (List the functional requirements here) interface with sensible name without special chars. so output of ifconfig etc can be parsed without special treatment. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Just use a standard name like "vdsmdummy" or "ovirt_vdsmdummy" 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? Not to my knowledge. But there are other companies that have had problems and additional work because of this. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? No. It's not an urgent, major issue, but one that can create problems in various unexpected places. 9. Is the sales team involved in this request and do they have any additional input? no 10. List any affected packages or components. vdsm 11. Would the customer be able to assist in testing this functionality if implemented? probably, but should not be necessary.
The intention behind the funny bridge name was that it was impossible to create such a new via Engine. An evil customer could create a network named ovirt_vdsmdummy which would collide with vdsm's own dummy. Solving this bug is a bit of a headache. It requires a lot of attention to the upgrade path, in particular if the cluster has hosts with VMs that are still connected to ;vdsmdummy;. Regardless, other applications and tools should not assume that interface names do not include ';' or '&', and use proper quoting when needed. Robert, could you provide more details on the rkhunter result?
Hi, we know that it would be the best if all applications would not assume common interface names, but there are some that do. We already fixed facter to work correctly. To prevent future hassle for us and others I opened the case to try to fix the root of the problem. I assume rhev has some detection to check whether a network collides with an existing interface. or where should this collision be a problem? rkhunter is a script that tries to detect suspicious files that could indicate rootkits.
On what did you run the rkhunter script? Could you solve the apparent bug there with proper quoting?
yes, the rkhunter script seems to work correctly now. But the the request was not to fix our immediate symptom, rather than removing the probable cause of further issues by using a normal name for the interface.
Let us consider a nicer naming when dropping the Linux bridge in favor of OVS
Closing old RFEs, please reopen if still needed. Patches are always welcomed.
BZ<2>Jira Resync