Hi, can someone tell me if these instructions still work with fedora35 to build a bridge?
https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Gu...
This is for a headless server that I'd like to use to build a bunch of virtual machines, and would like to be able to assign real IPs to them.
Thanks, Alex
On Mon, 24 Jan 2022 17:45:14 -0500 Alex wrote:
Hi, can someone tell me if these instructions still work with fedora35 to build a bridge?
They might, but resistance is futile, you might as well use NetworkManager now before it becomes the only option.
I setup a bridge on my system with nmcli (since the GUI interface was hopeless). I think these notes might be correct:
nmcli con show nmcli con add ifname br0 type bridge con-name br0 nmcli con add type bridge-slave ifname eth0 master br0 nmcli con down "Wired connection 1" nmcli con up br0 nmcli con show nmcli con mod br0 ipv4.ignore-auto-dns yes nmcli con mod br0 bridge.mac-address <mac of eth0 here> nmcli con modify br0 bridge.stp no
You'd probably need different names for things here and there, but it does seem to work. I can give virtual machines connections on the br0 bridge and they correctly get IP addrs assigned by the DHCP server on my router.
Tom Horsley writes:
I setup a bridge on my system with nmcli (since the GUI interface was hopeless). I think these notes might be correct:
nmcli con show nmcli con add ifname br0 type bridge con-name br0 nmcli con add type bridge-slave ifname eth0 master br0 nmcli con down "Wired connection 1" nmcli con up br0 nmcli con show nmcli con mod br0 ipv4.ignore-auto-dns yes nmcli con mod br0 bridge.mac-address <mac of eth0 here> nmcli con modify br0 bridge.stp no
This looks correct to me. I can follow this; but I'll be darned if I'll remember any of this when I'll need to do it next time, myself. networkmanager is huge. The manual pages are detailed, extensive, and describe everything.
But there's just one problem. If you need to do a basic task, like that, you have absolutely no clue where to begin.
On Mon, Jan 24, 2022 at 9:21 PM Sam Varshavchik mrsam@courier-mta.com wrote:
Tom Horsley writes:
I setup a bridge on my system with nmcli (since the GUI interface was hopeless). I think these notes might be correct:
nmcli con show nmcli con add ifname br0 type bridge con-name br0 nmcli con add type bridge-slave ifname eth0 master br0 nmcli con down "Wired connection 1" nmcli con up br0 nmcli con show nmcli con mod br0 ipv4.ignore-auto-dns yes nmcli con mod br0 bridge.mac-address <mac of eth0 here> nmcli con modify br0 bridge.stp no
This looks correct to me. I can follow this; but I'll be darned if I'll remember any of this when I'll need to do it next time, myself. networkmanager is huge. The manual pages are detailed, extensive, and describe everything.
But there's just one problem. If you need to do a basic task, like that, you have absolutely no clue where to begin.
If you are an Ansible user, you might try the network system role - https://github.com/linux-system-roles/network/ available in https://src.fedoraproject.org/rpms/linux-system-roles or https://galaxy.ansible.com/fedora/linux_system_roles or https://galaxy.ansible.com/linux-system-roles/network
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 1/24/22 18:20, Sam Varshavchik wrote:
Tom Horsley writes:
I setup a bridge on my system with nmcli (since the GUI interface was hopeless). I think these notes might be correct:
nmcli con show nmcli con add ifname br0 type bridge con-name br0 nmcli con add type bridge-slave ifname eth0 master br0 nmcli con down "Wired connection 1" nmcli con up br0 nmcli con show nmcli con mod br0 ipv4.ignore-auto-dns yes nmcli con mod br0 bridge.mac-address <mac of eth0 here> nmcli con modify br0 bridge.stp no
This looks correct to me. I can follow this; but I'll be darned if I'll remember any of this when I'll need to do it next time, myself. networkmanager is huge. The manual pages are detailed, extensive, and describe everything.
But there's just one problem. If you need to do a basic task, like that, you have absolutely no clue where to begin.
Install "nm-connection-editor" and it's easy.
On Mon, 24 Jan 2022 19:17:06 -0800 Samuel Sieb wrote:
Install "nm-connection-editor" and it's easy.
Not remotely correct unless perhaps you are the author and know what the gibberish it presents means. All my attempts to use it mostly left me with all the controls disabled and no hint of what it might be wanting to enable them.
On 1/25/22 06:28, Tom Horsley wrote:
On Mon, 24 Jan 2022 19:17:06 -0800 Samuel Sieb wrote:
Install "nm-connection-editor" and it's easy.
Not remotely correct unless perhaps you are the author and know what the gibberish it presents means. All my attempts to use it mostly left me with all the controls disabled and no hint of what it might be wanting to enable them.
Controls? Gibberish? I have no idea what you're talking about. It allows you to create and edit any type of network interface or connection and uses normal English labels for everything. Somehow that's more confusing than trying to edit an ifcfg file?
On 1/25/22 12:52, Tom Horsley wrote:
On Tue, 25 Jan 2022 12:46:47 -0800 Samuel Sieb wrote:
It allows you to create and edit any type of network interface
Only if the "OK" button isn't grayed out.
There is no OK button now. But I do remember a long time ago that there was a field (I think it was a mac address) that somehow ended up with an invalid value that needed to be cleared before it could be saved. When was the last time you tried to use it?
On Tue, 25 Jan 2022 13:05:48 -0800 Samuel Sieb wrote:
When was the last time you tried to use it?
A few years ago no doubt. It wasn't just the OK button. Value fields I wanted to type in were inactive, etc. This is one of my many objections to "helpful" GUI tools. At least the command line tools usually print some kind of error if you try to do something impossible, which is at least a hint compared to just refusing to let you fill in fields.
On Mon, 24 Jan 2022 21:20:50 -0500 Sam Varshavchik wrote:
But there's just one problem. If you need to do a basic task, like that, you have absolutely no clue where to begin.
Without google, linux itself would be impossible :-). I got most of that from a google search when led me here:
https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkma...
Not all of it though, there were still a few more things for google to turn up (like setting bridge.stp making it start 100 times faster).
On Tue, 2022-01-25 at 09:24 -0500, Tom Horsley wrote:
But there's just one problem. If you need to do a basic task, like that, you have absolutely no clue where to begin.
Without google, linux itself would be impossible :-)
<rant> Perhaps not impossible, but certainly more difficult. I attribute this to the poor quality of much documentation. Gone are the good ol' days of UNIX when everything was in the man pages (as long as you had the patience to read them). Many tools nowadays don't even have a proper man page, if they have any at all (I'm looking at you, KDE), so you have to rely on a web browser even to read what help there is. </rant>
poc
On Jan 25, 2022, at 12:03, Patrick O'Callaghan pocallaghan@gmail.com wrote:
<rant> Perhaps not impossible, but certainly more difficult. I attribute this to the poor quality of much documentation. Gone are the good ol' days of UNIX when everything was in the man pages (as long as you had the patience to read them). Many tools nowadays don't even have a proper man page, if they have any at all (I'm looking at you, KDE), so you have to rely on a web browser even to read what help there is. </rant>
I do suggest you try the “nmcli” man page, and the “nmcli-examples” man page for examples.
I feel the documentation is quite good and exceeds what might have been there for the old ifcfg files. (which, iirc, were actually documented in a .txt file in /usr/share/doc and *not* a man page)
I know it’s fun to rag on the new (ish) things but NM is actually quite nice.
— Jonathan Billings
On Tue, 2022-01-25 at 16:24 -0500, Jonathan Billings wrote:
On Jan 25, 2022, at 12:03, Patrick O'Callaghan pocallaghan@gmail.com wrote:
<rant> Perhaps not impossible, but certainly more difficult. I attribute this to the poor quality of much documentation. Gone are the good ol' days of UNIX when everything was in the man pages (as long as you had the patience to read them). Many tools nowadays don't even have a proper man page, if they have any at all (I'm looking at you, KDE), so you have to rely on a web browser even to read what help there is. </rant>
I do suggest you try the “nmcli” man page, and the “nmcli-examples” man page for examples.
I feel the documentation is quite good and exceeds what might have been there for the old ifcfg files. (which, iirc, were actually documented in a .txt file in /usr/share/doc and *not* a man page)
I know it’s fun to rag on the new (ish) things but NM is actually quite nice.
I was commenting in general terms on Tom's observation about needing Google to understand some things. I'm well aware that some things do have proper man pages, but quite a few don't.
Anyway, this is really off-topic for the thread (hence the <rant></rant> brackets).
poc
Patrick O'Callaghan writes:
<rant> Perhaps not impossible, but certainly more difficult. I attribute this to the poor quality of much documentation. Gone are the good ol' days of UNIX when everything was in the man pages (as long as you had the patience to read them). Many tools nowadays don't even have a proper man page, if they have any at all (I'm looking at you, KDE), so you have to rely on a web browser even to read what help there is. </rant>
There's some of that, but this situation tends to be short lived. Anything that's poorly documented withers itself out, and a better-documented alternative emerges.
The bigger problem I see today is a combination of two things:
1) Stuff that's hideosly complicated and hundreds of times bigger than its predecessor. Compare the relative magnitude of nmcli's configuration, and /etc/sysconfig/network-scripts
2) Stuff that crammed down everyone's throat, for various non-technical reasons and, otherwise, they have no technical merit of advantage that anyone can identify and point to.
I'll just state for the record that I am not asserting that nmcli falls into this category.
On Tue, 25 Jan 2022 18:43:19 -0500 Sam Varshavchik wrote:
- Stuff that crammed down everyone's throat, for various non-technical
reasons and, otherwise, they have no technical merit of advantage that anyone can identify and point to.
At least NM had a reasonably valid reason - wireless was absolutely hopeless on linux before NM. It just took NM about 10 years to reach the point where it could do everything else network-scripts could already do.
Tom Horsley writes:
On Tue, 25 Jan 2022 18:43:19 -0500 Sam Varshavchik wrote:
- Stuff that crammed down everyone's throat, for various non-technical
reasons and, otherwise, they have no technical merit of advantage that anyone can identify and point to.
At least NM had a reasonably valid reason - wireless was absolutely hopeless on linux before NM. It just took NM about 10 years to reach the point where it could do everything else network-scripts could already do.
Agreed, and it's not just wifi but also VPN. I was able to come up with a turn-key script for automating a VPN setup for my VPN provider, and package it into an rpm. Plug: https://github.com/svarshavchik/fedora-nordvpn
I actually think NM falls only into the 1st category that I listed. It's hideously complicated, and just huge compared to network-scripts.
But that's not automatically a bad thing, and there are instances where simply the cost of complexity is worth it, and I think that NM, together with firewalld falls into that category.
What I think would really help with NM, and specifically nmcli, is to have nmcli upon request show each setting's description next to it. All of them are already documented in its man page. Just pull them out, verbatim.
So when I do "nmcli con show <uuid>" in addition to just the bare data dump, with cryptic names, I have a nice, brief, explanation of what each shown setting means. Every time I have to work with nmcli I end up burning a lot of time jumping back and forth between the man page and what nmcli shows me.
Tom Horsley writes:
Not all of it though, there were still a few more things for google to turn up (like setting bridge.stp making it start 100 times faster).
I do have a server with a bridge and a hosted VM that uses it. The server predated the existence of NetworkManager. At some point in the past I just removed
NM_CONTROLLED=NO
from /etc/sysconfig/network-scripts/ifcfg*, I just checked and nmcli returns "bridge.stp: no", in this situation.
The server takes an eternity to boot, but not because of this setting…
Am 24.01.2022 um 23:45 schrieb Alex mysqlstudent@gmail.com:
Hi, can someone tell me if these instructions still work with fedora35 to build a bridge?
https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Gu...
In addition to Tom’s answer, with F36 it will no longer work. There is a change proposal to remove ifcfg support completely and most contributors agree with that.
If you want your VMs to have access to the public network, then you have to share the host's public interface. The most convenient option is mac-vlan and to avoid a bridge. You don’t need to configure the host interface, but just the VMs to use „direct attachment“ in KVM/libvirt-speech. See Fedora Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-vm-ins... (it’s the staging version).
Konfiguration is much easier and it causes less system load. The only disadvantage is that the VMs cannot communicate directly with the host. But it is usually better to use an internal, protected network for this.
If the host has a second physical interface that you want to use for an internal, protected network between VMs and the host as well as other hosts and VMs on that internal network, you have to reconfigure the second, internal network. My Fedora Server Doku is not yet ready, but you have to reconfigure the second interface as a bridge (because the VMs should be able to communicate with the host and vice versa). You man do (if is enp6s0 here)
(a) create a bridge and assign it the internal physical interface. IPv4 is static, no IPv6 for internal network: […]# nmcli con add ifname vbr6s0 type bridge con-name vbr6s0 \ bridge.stp no […]# nmcli con mod vbr6s0 ipv4.method static \ ipv4.address "10.10.10.XXX/24" \ ipv4.gateway "10.10.10.10" \ ipv4.dns "10.10.10.1" \ ipv4.dns-search "localnet" \ ipv6.method disabled \ connection.zone "trusted" […]# nmcli con add ifname enp6s0 type bridge-slave \ master vbr6s0 con-name vbr6s0-slave-enp6s0 \ connection.zone "trusted" […]# nmcli con show vbr6s0
You should specify dns-search to enable systemd-resolved to resolve internal node names (i.e. not FQDN)
(b) deactivate the original physical interface and activate the bridge:
[…]# nmcli con down enp6s0 […]# nmcli con up vbr6s0 […]# nmcli con reload
If your internal network is virtual only (w/o physical interface), it’s best to use libvirt virbr0. See Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-instal... about host configuration. (Leave out "stg." in the url to get the current published version)
Best Peter
Hi, can someone tell me if these instructions still work with fedora35 to build a bridge?
https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Gu...
In addition to Tom’s answer, with F36 it will no longer work. There is a change proposal to remove ifcfg support completely and most contributors agree with that.
If you want your VMs to have access to the public network, then you have to share the host's public interface. The most convenient option is mac-vlan and to avoid a bridge. You don’t need to configure the host interface, but just the VMs to use „direct attachment“ in KVM/libvirt-speech.
This is an internet facing server only - only one interface and no internal network. I should have mentioned the VMs (kvm) will have their own public IPs so we don't have to reverse masq them.
See Fedora Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-vm-ins... (it’s the staging version).
Konfiguration is much easier and it causes less system load. The only disadvantage is that the VMs cannot communicate directly with the host. But it is usually better to use an internal, protected network for this.
It's only an apache server, so until just now, it didn't even have cockpit installed. So instead of just using vi to edit the text files directly, I had to install 140+ packages to configure/enable cockpit, lol. It does look kinda nice, though. I'm an old-school sysadmin from before NetworkManager existed.
If the host has a second physical interface that you want to use for an internal, protected network between VMs and the host as well as other hosts and VMs on that internal network, you have to reconfigure the second, internal network. My Fedora Server Doku is not yet ready, but you have to reconfigure the second interface as a bridge (because the VMs should be able to communicate with the host and vice versa). You man do (if is enp6s0 here)
(a) create a bridge and assign it the internal physical interface. IPv4 is static, no IPv6 for internal network: […]# nmcli con add ifname vbr6s0 type bridge con-name vbr6s0 \ bridge.stp no […]# nmcli con mod vbr6s0 ipv4.method static \ ipv4.address "10.10.10.XXX/24" \ ipv4.gateway "10.10.10.10" \ ipv4.dns "10.10.10.1" \ ipv4.dns-search "localnet" \ ipv6.method disabled \ connection.zone "trusted" […]# nmcli con add ifname enp6s0 type bridge-slave \ master vbr6s0 con-name vbr6s0-slave-enp6s0 \ connection.zone "trusted" […]# nmcli con show vbr6s0
I'm not sure I understand this part - do I substitute my public IP for the localnet above, or is the config different in some other way when using public IPs and not using virbr0?
Tips on how to set it up to support a kvm/qemu instance with a public IP would be appreciated.
Thanks, Alex
You should specify dns-search to enable systemd-resolved to resolve internal node names (i.e. not FQDN)
(b) deactivate the original physical interface and activate the bridge:
[…]# nmcli con down enp6s0 […]# nmcli con up vbr6s0 […]# nmcli con reload
If your internal network is virtual only (w/o physical interface), it’s best to use libvirt virbr0. See Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-instal... about host configuration. (Leave out "stg." in the url to get the current published version)
Best Peter
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 1/24/22 18:47, Alex wrote:
This is an internet facing server only - only one interface and no internal network. I should have mentioned the VMs (kvm) will have their own public IPs so we don't have to reverse masq them.
Tips on how to set it up to support a kvm/qemu instance with a public IP would be appreciated.
That's much easier then. Just use the "mac-vtap" option when configuring the VM's network interface.
Am 25.01.2022 um 03:47 schrieb Alex mysqlstudent@gmail.com:
I'm an old-school sysadmin from before NetworkManager existed.
Welcome to the club. But I still learned to appreciate Cockpit. It saves a lot of typing (and typos).
Nevertheless you can use mac-vlan / mac-vtap to connect your VM(s) to the internet instead of using a bridge. As an old-school sysadmin you may use virsh and something like:
[…]# virt-install --name <VM_NAME>\ --memory 4098 --cpu host --vcpus 3 --graphics none\ --os-type linux --os-variant fedora35\ --graphics none \ --location </PATH/TO/FEDORA.ISO> \ --disk /var/lib/libvirt/images/<VM_NAME>.qcow2,format=qcow2,bus=virtio \ --network type=direct,source=<HOST_IF_NAME>,source_mode=bridge,model=virtio
The last line defines your network connection vor the VM. The „type=direct“ specifies mac-vlan / mac-vtap as the connection technology to use. You have to adjust the source= according to the name of your machines interface, of course.
When installation completed you can login to your VM using
[…]# virsh console <VM_NAME>
Everything in the terminal and nothing with GUI. :-)
If the host has a second physical interface that you want to use for an internal, protected network between VMs and the host as well as other hosts and VMs on that internal network, you have to reconfigure the second, internal network. My Fedora Server Doku is not yet ready, but you have to reconfigure the second interface as a bridge (because the VMs should be able to communicate with the host and vice versa). You man do (if is enp6s0 here)
(a) create a bridge and assign it the internal physical interface. IPv4 is static, no IPv6 for internal network: […]# nmcli con add ifname vbr6s0 type bridge con-name vbr6s0 \ bridge.stp no […]# nmcli con mod vbr6s0 ipv4.method static \ ipv4.address "10.10.10.XXX/24" \ ipv4.gateway "10.10.10.10" \ ipv4.dns "10.10.10.1" \ ipv4.dns-search "localnet" \ ipv6.method disabled \ connection.zone "trusted" […]# nmcli con add ifname enp6s0 type bridge-slave \ master vbr6s0 con-name vbr6s0-slave-enp6s0 \ connection.zone "trusted" […]# nmcli con show vbr6s0
I'm not sure I understand this part - do I substitute my public IP for the localnet above, or is the config different in some other way when using public IPs and not using virbr0?
This variant does not apply to you, because your server has only one interface (which is needed for public access). It refers to the case where the server has 2 (or more) physical interfaces and the 2nd interface is to be used for a separate, non-public, protected internal network.
Tips on how to set it up to support a kvm/qemu instance with a public IP would be appreciated.
Basically you will first install Fedora Server the usual way. Afterwards install libvirt / KVM and then one or more VMs.
Our Fedora Server documentation contains a detailed description of those steps for the most current release 35 and tips what possible alternative to choose.
Installation: https://docs.fedoraproject.org/en-US/fedora-server/server-installation/. # (published version previous release) https://docs.stg.fedoraproject.org/en-US/fedora-server/server-installation/ # (staging, most current release)
For adding visualisation and VMs see: https://docs.fedoraproject.org/en-US/fedora-server/server-virtualization/ # (again published version previous release) https://docs.stg.fedoraproject.org/en-US/fedora-server/server-virtualization... # (again staging, most current release)
You can drop Cockpit if you don't like it.
In case of further questions, please don’t hesitate to ask, either here or on Server list (server@lists.fedoraproject.org)
Best Peter
On Tue, 25 Jan 2022 01:48:24 +0100 Peter Boy pboy@uni-bremen.de wrote:
If you want your VMs to have access to the public network, then you have to share the host's public interface. The most convenient option is mac-vlan and to avoid a bridge. You don’t need to configure the host interface, but just the VMs to use „direct attachment“ in KVM/libvirt-speech. See Fedora Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-vm-ins... (it’s the staging version).
Konfiguration is much easier and it causes less system load. The only disadvantage is that the VMs cannot communicate directly with the host. But it is usually better to use an internal, protected network for this.
This, for me, is a fatal limitation. The web server needs to access the database server and so on. At home I have just one network and every thing is internal. At work we have an internal network and all internet-facing services are on an isolated network with an industrial grade firewall and application filter severely restricting access from the internet. All the hosts are already on an “internal” network of some variety, so setting up a another one seems redundant.
I also feel that configuring the host for bridge mode is much more convenient than installing a separate physical network.
Jim
Am 25.01.2022 um 15:30 schrieb James Szinger jszinger@gmail.com:
On Tue, 25 Jan 2022 01:48:24 +0100 Peter Boy pboy@uni-bremen.de wrote:
...
Konfiguration is much easier and it causes less system load. The only disadvantage is that the VMs cannot communicate directly with the host. But it is usually better to use an internal, protected network for this.
This, for me, is a fatal limitation. The web server needs to access the database server and so on. At home I have just one network and every thing is internal.
In this case libvirt virtual network is for you. It’s already there, you just have to use it. That network create an internal, protected (from public) network. The typical use case is a public service like web server that will access a service you want protect from public access, typically a database. You won’t make the database accessible from the public. If you web server should be able to access the database over the public interface, you must open the firewall port and everyone from outside can access the database as well and try to attack it.
Therefore a common structure is to install service, esp. a database natively on the host and isolate the host from internet as far as possible, usually you just allow ssh or vpn. Public service are installed in a VM with as publicly accessible as needed.
At work we have an internal network and all internet-facing services are on an isolated network with an industrial grade firewall and application filter severely restricting access from the internet. All the hosts are already on an “internal” network of some variety, so setting up a another one seems redundant.
Yes, the text I linked does not set up another network but makes the internal network accessible for the VMs
I also feel that configuring the host for bridge mode is much more convenient than installing a separate physical network.
There is no additional separate physical network involved besides those your host is already connected to (1 network at your home, 2 networks at work).
Please, read the linked text again and give me a hint, where the wording is misleading so we can improve that.
Thanks Peter