Charles Duffy's questions

The NFSv4 idmap approach allows a great deal of flexibility in terms of how users and accounts are mapped between the NFS server and the local system -- but with this comes significant configuration complexity. If trying to build a turnkey solution that works with any site-local NFS server, this can be particularly unfortunate.

Is there a reasonable mechanism for a Linux NFSv4 client to available to mount an NFS server with a different user account mapped to the anonymous user for different subtrees, or to have different mounts off the same server with different idmaps assigned?

That is to say:

/mnt/server-a/foo ## in this subtree, unknown owners are mapped to the local account "foo"
/mnt/server-a/bar ## in this subtree, unknown owners are mapped to the local account "bar"

I'm even considering approaches such as loopback fuse-based servers -- though the performance impact would make this quite unfortunate.

I have a StrongSWAN configuration inspired by the trap-any test case:

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1

conn lan
        right=%any
        leftsubnet=fd12:3456:7890:abcd::/64
        rightsubnet=fd12:3456:7890:abcd::/64
        type=transport
        authby=psk
        auto=route

This automatically negotiates a SA with any system on my local subnet I try to connect with; in general, it's doing the Right Thing.

However, when I multicast to my whole subnet:

ping6 -I fd12:3456:7890:abcd::1234 ff02::1

...not only do I get responses from, and set up security associations with, the other systems (yay!), but I have two separate security associations generated communicating with the local host itself, with fd12:3456:7890:abcd::1234 as both initiator and responder.

My first thought was to avoid this like so:

conn local
       type=passthrough
       left=fd12:3456:7890:abcd::1234
       right=fd12:3456:7890:abcd::1234

...but that doesn't actually prevent the loopback connections.

By contrast, with:

conn local
        type=passthrough
        right=%any
        rightsubnet=fd12:3456:7890:abcd::1234/128

...no security associations are established at all.

How can I avoid SAs for local traffic in this mode?

For obvious reasons, best practice in building clusters that require distributed consensus is to use 3, 5, or another node count that has a tiebreaker in place.

Sometimes, however, one has two physical devices and wants to cluster them. One way to get better availability than having no clustering at all, in these cases, is two give one of these systems two votes. One way to do this with Zookeeper is to configure a hierarchical quorum, and give one of the nodes two votes:

# 2-node zookeeper configuration that allows node-2 to fail without losing quorum
# ...node-1 cannot go down without losing quorum, *unless* these weights are first
# ...reconfigured; such configuration is allowed at runtime, with no service disruption!
group.1=1
group.2=2
weight.1=2
weight.2=1

In the original case, with each node having one vote, if either node failed then no quorum could be achieved. In this case, the node having only one vote is able to fail without bringing the other one down with it. Thus, we've successfully avoided having a second node make us less robust than we were when not clustered at all -- and for planned maintenance, when both nodes are present in the cluster we can update configuration with a new set of weights to allow group 1 but not group 2 to go offline without losing quorum.

...so, the question: How can this be achieved using etcd rather than zookeeper? Do I need to actually run two copies of etcd on node 1 (and, if we want to transfer this extra vote to node-2 to allow node-1 to be removed from the cluster, spin up a second copy there instead and decommission the second copy on node-1)? If so, can this be done without the overhead of having data synchronized to this instance (since its only purpose is to act as an observing voter)?

From zfs send -R -v pool/fs@snap:

send from @ to pool/fs@snap estimated size is 6.50T

...but from zpool list:

NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  3.62T  2.36T  1.27T    65%  2.87x  ONLINE  -

Can a zfs send stream really be several times larger than the pool from which it's taken?

Observed w/ ZFS on Linux 0.6.1.

I'm using OpenSSH certificates for a pool of hosts. That is to say, in ~/.ssh/known_hosts, there's an entry that looks thus:

@cert-authority service.redacted.com ssh-rsa ...

...and service.redacted.com is a round-robin DNS entry for which each system involved has a host certificate (see the HostCertificate entry in man sshd_config) signed as valid for service.redacted.com.

This works perfectly when wanting to connect to a randomly-selected system from the pool -- but what if someone wants to connect to a single, specific system from the pool, validating its host key as legitimate using the certificate authority given?

One thing I tried was thus:

service_name=service.redacted.com
specific_host=1.2.3.4
ssh -v -oHostKeyAlias="$service_name" "$specific_host"

...which results in the following:

debug1: Host 'service.redacted.com' is known and matches the RSA-CERT host certificate
Certificate invalid: name is not a listed principal
The authenticity of host 'service.redacted.com (1.2.3.4)' can't be established.

service.redacted.com quite certainly is a listed principal in the certificate; 1.2.3.4 is not.

I'm using programatically generated Ansible playbooks. In general, because playbooks are just YAML, this is straightforward. However, when using the "simple" key=value form, playbooks aren't pure YAML -- they include content embedded a shlex-parsable form.

To avoid the ambiguity in this form (is that key=value pair an argument to the command or an argument for ansible?), and have only a single format to parse and generate, I'm unconditionally using the complex args mechanism demonstrated by example in the ansible-examples repository.

This uses a syntax of the following kind:

action: module-name
args:
  key1: value1
  key2: value2

...which is well and good. However, when trying to use this form for the shell or command modules (whose documentation describes the actual command as being passed in an argument named free_form), this doesn't work so well:

action: shell
args:
  free_form: echo hello_world >/tmp/something
  creates: /tmp/something

When invoked, this runs the following:

/bin/sh -c " free_form='echo hello_world >/tmp/something'  "

...which is very much not what I'm trying to accomplish.

What's the right way to use Ansible modules taking "free-form" commands using pure YAML syntax?

According to the man page for launchctl (emphasis mine):

   -w   Overrides the Disabled key and sets it to false. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on-disk.

Because the current state of the disabled flag is no longer set in the .plist file itself, checking for the Disabled key is no longer an accurate way to tell if the service will run on next boot.

Where is this "elsewhere on-disk"? More to the point (and more importantly), how does one check whether this flag is set?

Also, is it possible to set a service to run on next boot without forcing it to start immediately (as with launchctl load -w /Library/LaunchDaemons/my-service.plist)?

I have a Windows Server 2003 system on which passwordless access to local UNC paths is possible using the server's unqualified hostname or its IP address, but not via its FQDN -- even when the hosts file is used to map that FQDN directly to 127.0.0.1.

That is:

• \\127.0.0.1\ - passwordless
• \\myhost\ - passwordless
• \\myhost.mydomain.com\ - brings up an authentication dialog

Unfortunately, I have a local application trying to resolve UNC paths including the host's FQDN.

I've tried resolving myhost.mydomain.com to 127.0.0.1 in both hosts and lmhosts, and calling ping myhost.mydomain.com at the command prompt gives the appearance that this resolution has taken effect; even so, attempting to open \\myhost.mydomain.com\ from Windows Explorer brings up a password prompt, while \\127.0.0.1\ does not.

The system is using an OpenDirectory server (Apple's Kerberos+LDAP directory service) for authentication.

How does one define a static route on MacOS X which persists through reboots? The only suggestion I've found on Google advises setting up a launchd service to run at boot, which seems like a horrible hack (does it survive a network restart without rebooting, for instance?)

To set up the route I need temporarily, I can run the following:

route add -net ${network} ${gateway} ${netmask}

How would I make this persist?