4:45 p.m.
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...
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
5:15 p.m.
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.
8:20 p.m.
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.
8:49 p.m.
On Mon, Jan 24, 2022 at 9:21 PM Sam Varshavchik <mrsam(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
9:17 p.m.
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.
8:28 a.m.
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.
2:46 p.m.
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?
3:05 p.m.
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?
3:17 p.m.
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.
8:24 a.m.
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-networ...
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).
11:02 a.m.
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
3:24 p.m.
On Jan 25, 2022, at 12:03, Patrick O'Callaghan <pocallaghan(a)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
6:16 a.m.
On Tue, 2022-01-25 at 16:24 -0500, Jonathan Billings wrote:
On Jan 25, 2022, at 12:03, Patrick O'Callaghan
<pocallaghan(a)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
5:43 p.m.
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.
6:12 p.m.
On Tue, 25 Jan 2022 18:43:19 -0500
Sam Varshavchik wrote:
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.
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.
7:22 p.m.
Tom Horsley writes:
On Tue, 25 Jan 2022 18:43:19 -0500
Sam Varshavchik wrote:
> 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.
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.
5:38 p.m.
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…
6:48 p.m.
Am 24.01.2022 um 23:45 schrieb Alex <mysqlstudent(a)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...
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-...
(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-ins... about host
configuration.
(Leave out "stg." in the url to get the current published version)
Best
Peter
8:47 p.m.
> 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...
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-...
(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-ins... about host
configuration.
> (Leave out "stg." in the url to get the current published version)
>
>
> Best
> Peter
>
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
9:15 p.m.
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.
1:47 a.m.
Am 25.01.2022 um 03:47 schrieb Alex <mysqlstudent(a)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-virtualizat... # (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(a)lists.fedoraproject.org)
Best
Peter
8:30 a.m.
On Tue, 25 Jan 2022 01:48:24 +0100
Peter Boy <pboy(a)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-...
(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
10:53 a.m.
Am 25.01.2022 um 15:30 schrieb James Szinger
<jszinger(a)gmail.com>:
On Tue, 25 Jan 2022 01:48:24 +0100
Peter Boy <pboy(a)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
821
days inactive
823
days old
23 comments
9 participants
participants (9)
-
Alex -
James Szinger -
Jonathan Billings -
Patrick O'Callaghan -
Peter Boy -
Richard Megginson -
Sam Varshavchik -
Samuel Sieb -
Tom Horsley