Ya I also pretty much use Virt-Manager/Virsh. I have a bare KVM server and an OpenStack box. I pretty much use Ansible/Terraform to spin up new instances on OpenStack.
Too bad ovs isnt in the repos for RHEL/CentOS. You can set up these private networks and connect them through a VXLAN with ovs. That way you can have something like a separate dev network on the same hosts and they can communicate between hosts.
Not available in the epel repo?
That is apparently the case unless my google--fu isn't up to snuff
Nope. It is available in Fedora though. If you want to install it you have to manually build the RPMs. While not hard to build it would be a pain to maintain updates.
OVS is used by oVirt so maybe the centos ovirt repo has it (or the ovirt stable repo)
I'm assuming it's just building the RPM since it's not in the normal repo.
I forgot before: You can also login to the admin interface and looking at the settings page. It'll give you a list of performance and security optimizations with links to instructions on how to make the changes.
Yeah that's where this all started. It only states that I need to...
Modify/enable the HSTS header to at least 15552000 seconds
PHP OPcache not properly configured and to make changes to the php.ini.
From that though, I got to the hardening and security guide and started to go even deeper down the rabbit hole.
I know you're doing this to learn, so this probably isn't needed at the moment. @scottalanmiller's guide to installing NextCloud with Salt has all the settings correct already according to that settings page.
If you are used to dealing with commands like mail from the mailx package, you may be used to apps that require a local MTA in order to send emails. In the config files of dnf-automatic however, we can instantly see that there is configuration for entering a non-local server. This means that dnf-automatic is implementing the SMTP protocol (SMTP) itself and is not dropping files in a queue.
[email]
# The address to send email messages from.
email_from = [email protected]
# List of addresses to send messages to.
email_to = root
# Name of the host to connect to to send email messages.
email_host = localhost
Because of this, we know that dnf-automatic is acting as an SMTP server on its own and must be configured for how your network is going to handle email and is not just relying on the default configuration of the system MTA.
No, this is jsut droping a mail to root. not email.
Wouldn't be better to say it's an SMTP client? Akin to Thunderbird?
But in this case it's not doing that, so would be confusing. Thunderbird is an SMTP client, but doesn't do the local drop piece.
What's not doing what? dnf-automatic isn't doing a local drop piece either. It uses SMTP to drop to localhost, not whatever mailx is doing to function.
So in that regard, it should be exactly like what Thunderbird is doing, no?
I don't believe that that is true, but maybe it is.
Well we know dnf-automatic will deliver to postfix on another host assuming that host is configured to allow relay from the dnf host. Am I missing something?
Does dnf-automatic not do both, though?
I don't know if dnf-automatic is doing the local drop piece like mailx does.
That doesn't include the repo so it can easily update via dnf does it? Although chrome generally updated by itself so you may not need that functionality.
For ease and speed and better management, I highly recommend using WP-CLI for all of your downloading, updating, configuration, etc. One like of WP-CLI will eliminate most of this installation, while making it easier to maintain in the long run.
