Robert Siemer's questions

Which element in a vagrant-libvirt-qemu/kvm-chain is responsible to actually configure the VM? Like editing the network configuration files. Wouldn't that totally depend on the details of the OS of the VM?

As an example, I got the following lines in the Vagrantfile:

config.vm.box = "archlinux/archlinux"
config.vm.network :private_network, :libvirt__network_name => "default", :mac => "52:54:00:00:00:1f", :ip => "192.168.30.7"

...and the VM ends up with dhcpcd (the client daemon) on all interfaces while systemd's networkctl shows that it manages all interfaces itself (one with static configuration, clearly conflicting with the dhcpcd). -- Only one of them should be in charge of any interface...

So what entity dropped files in /etc/systemd/network? How was that entity so sure that systemd is being used in that VM anyway? Is that entity (which turns the knobs of the VM configuration) documented somewhere with those details?

I’m starting with SPF on my (email) domain. (No DKIM or DMARC yet.)

I see little usefulness in HELO identity checking in SPF and am thinking about setting the HELO identity to my domain (instead of the hostname) or the IP of the machine.

Apart from the following points, what is SPF HELO checking good for? What points stand against using IP or domain as identity in SMTP clients?

• it is against (the spirit of) the standard (I’m not a big fan of following the standard just to follow the standard, especially if it does not break a MUST.)
• bounces’ and notifications’ empty MAIL FROM will be checked against the HELO identity (It is acceptable for me if those notifications to outside systems don’t float with the SPF credibility of my IP/domain.)
• to filter spammers who can not setup a DNS TXT record on any random single domain (the one they plan to use for HELO)

It seems that Postfix does not allow hostnames in the smtp_bind_address config parameter. But it does allow hostnames in inet_interfaces.

For SPF I want to make sure which address SMTP-clients bind to and I wanted to do this with an IP-independent configuration (like I always do).

Is there a way to enable hostnames for smtp_bind_address or any other way around this? The point is to leave the IP out of the configuration file(s).

(There is no DNS/networking involved in resolving those hostnames via /etc/hosts.)

On a Linux MD software RAID1 I removed a failed drive and added a new one. (All fine now.) The old drive and the new were never in the system at the same time.

Do I see that right, that adding the old drive to the system (for examination) will not hinder the MD assembly on boot in any way?

I assume that:

• MD will see 3 partitions that belong(ed) to the same RAID,
• but will also know that 2 of those are still part of the RAID and 1 is not

Which superblock data will MD help to sort this right? Is there a “not part of the RAID at the moment” bit? What data makes it clear to the MD subsystem that the old partition is not in fact the sole member of a degraded RAID?

Did the new device/partition get a fresh random member UUID on RAID rebuild?

Adding the old drive and confusing MD could be catastrophic if it chooses the wrong devices for the array. I want to avoid that.

Is there something like local = left which I could use in the strongSwan configuration?

I don’t want to use any IP-addresses, as they might change. And I don’t want the server to guess it, I want to fix it that way beyond any doubt.

In all of my “client-to-site” configurations I could not copy over the configuration to the other side unmodified. Not even the connection-section alone. Together with the fact that there seems no way to force it, this left/right-division is really not to my liking...

StrongSwan (as responder) selects a configured connection (conn section in ipsec.conf) for each incoming initiator key exchange intent.

At which times does strongSwan pick a connection configuration? Does it narrow possible connections one-by-one based on the knowledge gathered so far?

E.g. in an IKEv2-exchange, the first packet does not contain the identifier (“rightid”) yet, but connections with keyexchange=ikev1 are out of the question already.

The first response (in case no cookies are involved) should already indicate the algorithms selected for the IKE SA, so some connection has to be selected. How could strongSwan possibly do this at that point?

Assuming timers set like in the Linux implementation or as suggested in RFC4960:

When does an idle SCTP association timeout, when the peer disappears?

a) let’s assume HEARTBEAT is switched off for all destination addresses.

I guess it never does, because nothing is sent, so nothing gets lost.

b) with normal HEARTBEATs, both peers single homed.

• Association.Max.Retrans is 10 times
• RTO.Max is 60 seconds

After HEARTBEAT kicks in (when?) the upper limit is something related to 10×60s (=10 minutes). Who knows the details?

c) is it different if one or both sides are multihomed? Or if the association has a lot of data to send?

I’m not sure if the multihoming case is different at all (timeouts faster or slower?). – And if data is to be sent: I guess the timeout is still the same minus average time for the HEARTBEAT to kick in.