Michuelnik's questions

I would like to integrate HashiCorp vault into our current setup of consul + consul-template and was a bit surprised to find no option for consul-template to fetch the vault servers from consul's service discovery.

This is the configuration doc regarding vault:

# This denotes the start of the configuration section for Vault. All values
# contained in this section pertain to Vault.
vault {
  # This is the address of the Vault leader. The protocol (http(s)) portion
  # of the address is required.
  address = "https://vault.service.consul:8200"

Is this a missing feature? Isn't it missing because I miss something like it's there and badly documented or that my approach misses something?

Now I am going to run a one-shot consul-template against consul to generate consul-template's vault config section before consul-template can really start.

I am maintaining an office network with several VLANs. These VLANs are terminated by a redundant pair of Linux boxes as router. Between those I am running VRRP (with keepalived). On failure I am shifting my (virtual) gateway IPs between the two boxes. For IPv4 I am sending a bunch of GARPs afterwards to update the neighbour cache.

How should I proceed with IPv6? From the specs I would guess to do the same, just send an ND NA (with the S bit unset). Would that be right? If - what would be the preferred way for this? Unfortunately I was not able to find a tool like arping for GARP. Any Hints?

Thanks!

I have a linux (debian) router with two internet connections (A) and (B).

(A) is preferred, (B) is fallback.

I want to monitor the internet connection (and not only the availability of the gateways!) and change the default route appropriately.

1. If (A) is not providing internet, switch to (B)
2. If (A) is providing internet again, switch back to (A).

Only problem I have is in case (2). My routing table points towards a working internet so I cannot easily detect whether internet is working over link (A) again.

I am search for a ping or traceroute (or other diagnosis-tool) which can select the next-hop explicitly.

• ping -r looks promising, but can only ping a host on the lan. (It only has to write another destination address in the packet, damnit!)
• traceroute -g gateway looks even more promising and nearly does what I want - but sets source routing options which my next-hops deny. (Not within my administrative boundary...)

I just want a $ping, that can:

• select a source interface (and address)
• select a next-hop on that interface
• ping any arbitrary ip address

I could do evil trickery with policy-based routing but that would have production impact for all users. I would like to see a side-effect-free solution....

Is there a way to name a VLAN interface arbitrarily like eth72 or ext19 instead of the four standard nameing schemes eth0.72, vlan19 (and the padded variations)?

Don't have no clue. Perhaps udev?

I want to disable tcp-offloading ("TOE") on my debian servers.

ethtool -K .....

I have some wishes, though:

Integrate it cleanly into debian

This reads: no rc.local, I would also like to avoid pseudo-rc-scripting...

I would guess, it's installing ethtool and using the pre-up.d/-Hook which deconfigures TOE using options from /etc/network/interfaces.

I would like to deconfigure all my (future) servers in a generic fashion using FAI. (since fai is already in place - and wanted!) What about toe-options that are not supported on some hardware? Will networking fail if a non-existing-option should be disabled? I guess it should be robust not to do so, but this does not seem to be my wanted solution, either.

It clutters the config very much, since atm there are 11 options! Using multiple NICs this smells error-prone to me.

Isn't there a more generic solution? I have a sysctl in mind, but did not find one yet. My wish was:

echo 0 > /proc/sys/net/core/enable_tcp_offloading

PS: I'm quite surprised to find my "newer hardwares" to have TOE enabled by default, because of this: http://www.linuxfoundation.org/collaborate/workgroups/networking/toe

Simple OpenVPN Setup with SSL Authentication.

SSL-Setup: Root-CA > Intermediate-CA > Issuing-CA

All certificates (vpn-server and -clients) are issued by the "Issuing-CA".

I tried to use the certificate of the Issuing-CA as OpenVPN ca ca.pem parameter in the openvpn (server- and client-) config.

This did not work.

I had to add the complete certificate chain to the ca.pem. Then it worked.

I thought the ca parameter specifies trusted CAs. I do not want to include the whole certificate chain since I do not see the necessity for this! Contrary - this seems dangerous to me - since the Root-CA and the Intermediate CA can issue certificates for CNs that are used in the VPN! I would classify this as a security risk.

Is there a way to set a trust anchor to a non-root-CA?

I'm running two "services" that are served in linux kernel-space:

• Linux Netfilter Firewall ("iptables")
• Linux Virtual Server Loadbalancer ("IPVS", "LVS")

Now I want to (performance-)monitor my "application" like any other software I am running. What would that basically be? CPU-Time and Memory.

How do I get these out of the kernel? Memory consumption of iptables might be estimated by the size of the connection tracking table, same for ipvs. It's okay for me, but any hints are welcome.

But - what about the CPU time spent for processing Routing, Firewalling and Loadbalancing?

Does "system" time include processing of packet-forwarding and -filtering? What about ipvs-handling?

I'm running keepalived under Debian (Lenny, Squeeze) in a fairly simple setup, I'm just (ab)using it as a VRRP daemon to decide the mastership between two equal machines for some virtual IPs. All the magic happens in the notify-script.

When I completely stop the daemon (using debian's init-script) keepalived does not run the notify-script for backup or at least fault mode, which is what I would suspect and need.

I could "fix" the rc-script with some unwanted effects - the notify-script would be hard-coded into the rc-script introducing an unwanted coupling of these two and the mess of porting the patch to the next debian versions so this is not the way I really want to go...

Any hints for a cleaner solution to this problem?

vrrp_instance FOORRP {
  virtual_router_id 42
  interface eth0
  state BACKUP
  priority 200
  nopreempt
  authentication {
    auth_type AH
    auth_pass foobar42
  }
  notify "/usr/local/bin/vrrp-state"
  virtual_ipaddress {
    127.0.0.2
  }
}

PS: the use of the "three notify_"-scripts does not change anything

PPS: in the changelog (Release 1.1.16) there is something mentioned, that somehow fits my problem (though I am not using anything lvs-related in keepalived), but I am using a newer version (1.1.20): "notify_down isn't executed for working real servers on keepalived shutdown."