Chris Tonkinson's questions

At the top of my State file, I have:

{% if grains['os'] == 'Ubuntu' %}
  {% set ubuntu = True %}
  {% set arch = False %}
{% elif grains['os'] == 'Arch' %}
  {% set ubuntu = False %}
  {% set arch = True %}
{% endif %}

Later on,

{% if ubuntu %}
cron:
{% elif arch %}
cronie:
{% endif %}
  pkg.installed
  service.running:
    - enable: True

But this isn't working; my conditionals are rendering nothing (empty strings). Even if a small refactoring would get the job done, this smells to me.

Is there a more idiomatic way to alternate small details like this with Salt without so much templating boilerplate?

With Puppet you can set Resource Default Statments:

File {
  backup => '.puppet-bak',
  ensure => present,
  group  => 'root',
  mode   => '644',
  owner  => 'root',
}

and if I later have a file such as this it will inherit the default settings defined above.

file { '/etc/postfix/main.cf':
  source => "$file_root/etc/postfix/main.cf"
}

Is the same, or similar, possible with Salt to avoid a ton of duplicate code? How?

I have recently configured my own mail server (Linux-based postfix + dovecot scenario). This is just for personal use - I have no bulk mail going out, no automatically generated mail outbound from the host, nothing like that. I've gone through the trouble to configure all the additional fun-to-debug email DNS records:

@                 IN  TXT  v=spf1 +mx -all
_domainkey        IN  TXT  o=-; [email protected]
mail._domainkey   IN  TXT  v=DKIM1; h=sha256; k=rsa; s=email; p=deadbeef
_adsp._domainkey  IN  TXT  dkim=all
_dmarc            IN  TXT  adkim=s; aspf=s; fo=1; p=none; pct=100; rf=afrf; ri=86400; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; v=DMARC1;

I've got an IP that isn't on any blacklists, a PTR correctly configured, DKIM signatures validate perfectly, I thought everything was set up correctly.

But now I can't contribute to mailing lists. When I send to the list address, sometimes the message goes into a black hole, sometimes I get an email to my authfail@ address, and in other cases I see entries I believe are related in reports sent to aggrep@.

My theory is that the SPF policy is too restrictive. The mailman (or other) list server is acting as an SMTP relay for my messages, right? So I changed

@                 IN  TXT  v=spf1 +mx -all

to

@                 IN  TXT  v=spf1 +mx ~all

making the default action a softfail instead of a hardfail. The problem is, I don't want to go around spamming lists for no good reason to test this change. Has anyone else been here before and can verify/refute my theory?

EDIT 1:

Thinking back, and thanks @Alex for setting me straight, I really haven't provided enough data to make an accurate assessment. Here's an example of a notice I received on my authfail@ address when attempting to post to a mailing list:

This is a spf/dkim authentication-failure report for an email message received from IP 66.211.214.132 on Thu, 10 Jul 2014 20:58:52 +0800.
Below is some detail information about this message:
 1. SPF-authenticated Identifiers: archlinux.org;
 2. DKIM-authenticated Identifiers: none;
 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures;

For more information please check Aggregate Reports or mail to [email protected].



Feedback-Type: auth-failure
User-Agent: NtesDmarcReporter/1.0
Version: 1
Original-Mail-From: <[email protected]>
Arrival-Date: Thu, 10 Jul 2014 20:58:52 +0800
Source-IP: 66.211.214.132
Reported-Domain: example.com
Original-Envelope-Id: w8mowEA5UUwMjr5TlWQfBA--.250S2
Authentication-Results: 126.com; dkim=fail (signature error: RSA verify failed) header.d=example.com; spf=pass [email protected]
DKIM-Domain: example.com
Delivery-Result: delivered

Looks to me like this is a DKIM signature failure, but I have no idea why. Is the receiving server trying to verify my DKIM signature against the mailing-list-server's key, or vice versa? For some reason, I wouldn't expect this to happen - I remember reading somewhere that in cases like this Relays and such will sometimes remove/munge headers like this to ensure these types of failures don't occur?

EDIT 2:

Thanks to @Christopher Karel for referencing a DMARC report parsing tool at dmarcian.com. The lions share of entries are listed as forwarders (which makes sense). There is one server (*.mailhop.org) listed as "preserv[ing] DKIM" - I've sucessfully sent mail over one of the Ruby language forums which has worked, and I know from my research they use mailhop.org.

Under the category "Servers that break DKIM signatures (or create spoofed signatures)" are listed *.archlinux.org, *.google.com, *.mailhop.org (dunno why this appears here, maybe another list I'm on uses them as well in a different configuration), among others and the lists I've been most active on are Arch and a few hosted by Google Groups so this makes sense. About 400 messages in total - I haven't sent nearly that many messages, so I guess maybe it's counting retries.

I'm getting depressed - at the moment it seems like my choices are:

1. Keep SPF, DKIM, DMARC, and ADSP and give up using mailing lists, or
2. Drop this DNS security/reporting layer and have my normal outgoing mail rejected by Google, Yahoo!, Live, etc.

I've got 6 physical drives in RAID-Z2, which I intend to one-by-one convert to dm-crypt devices.

My process was roughly:

1. dd if=/dev/zero of=/dev/sdf
2. Create keyfile /etc/crypttab.d/crypt-1.key
3. cryptsetup luksFormat /dev/sdf
4. Append crypt-1 <raw-disk-uuid> /etc/crypttab.d/crypt-1.key luks to /etc/crypttab
5. cryptsetup luksOpen /dev/sdf crypt-1
6. zfs replace my_pool <raw-disk-uuid> /dev/mapper/crypt-1

Once the resilvering was finished (which worked fine), I rebooted the machine to verify the setup before continuing to other disks. What I found, however, was that ZFS labeled crypt-1 as UNAVAIL.

ls /dev/mapper verified that dm-crypt activated the LUKS container correctly. Running zpool online my_pool crypt-1 causes ZFS to begin resilvering but then completes and resumes healthy operation in a manner of seconds.

I'm guessing the dm-crypt device is simply not loaded when ZFS first tries to accesses my_pool? Is it a question of load-order or do I need to be using a different identifier for the LUKS device in /etc/crypttab? How do I ensure that ZFS sees these LUKS devices on reboot?

This is a systemd box (Arch) if that matters.

Thanks!

EDIT 1:

During cryptsetup creation, I used the SCSI identifiers (e.g. /dev/sdf) to initialize the device with LUKS. However, in /etc/crypttab I'm specifying the devices through the UUID of the underlying physical disk. Is the cryptsetup utility sensitive to how you identify targets? In other words, do I need to re-do my cryptsetup and pass it the disk UUID instead of the SCSI name?

EDIT 2:

I see the following ls -alsvh /dev/disk/by-id:

0 lrwxrwxrwx 1 root root  10 Jul  8 08:18 dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 -> ../../dm-0

From what I know, if it's in /dev/disk/by-id it is - by definition? - not subject to change (even across reboots). I will replace the definition of the dm-crypt-name locker-1 in my zpool with the id-name /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 and report back. Same drive, same LUKS container, just a different way of addressing it.

EDIT 3:

My proposal from edit #2 above did not work. I had to wipe the drive and re-cryptsetup the device because ZFS would not allow me to replace the device with itself. After resilvering was complete I rebooted and zpool status is DEGRADED and device dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1 is UNAVAIL.

It's worth noting that locker-1 does appear in ls /dev/disk/by-id as well as lsblk, so it is being loaded correctly. I can verify this by running:

zpool online inground dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1

Which exits cleanly, and brings the device back into the pool.

Perhaps this is due to the load order of different modules during boot? Maybe the activation of dm-crypt devices is done such that ZFS begins importing pools before the LUKS container is properly open?

I'm writing an External Node Classifier for my Puppet infrastructure, and I have the need to manipulate the /etc/hosts file on each node. The following (due to the duplicate key) is invalid YAML:

---
  host:
    name: www1.example.com
    host_aliases: www1
    ip: 1.2.3.4
  host:
    name: www2.example.com
    host_aliases: www2
    ip: 1.2.3.5

I see this related answer, which has the following code:

host {
  # Public IPs - eth0
  'front-01': ip => '192.168.1.103';
  'front-02': ip => '192.168.1.106';

  # Private IPs - eth1
  'priv0-0': ip => '192.169.40.201';
  'priv0-1': ip => '192.169.40.202';
  'priv1-0': ip => '192.169.40.207';
  'priv1-1': ip => '192.169.40.208';

  # Virtual IPs - eth0:1
  'vip-01': ip => '192.169.50.202';
  'vip-02': ip => '192.169.50.205';
}

However,

1. It's not immediately obvious to me what's actually going on here.
2. I can't find documentation for this anywhere.
3. Because these (don't look like) class parameters - and because of #1 and #2 above - it's also not obvious to me how I could translate this into YAML.

A naive guess would be:

'host':
  'www1':
    'ip': 1.2.3.4
  'www2':
    'ip': 1.2.3.5

But because of #2 above, I'm not comfortable moving forward with this in production. My question then:

Where can I find documentation on using the host class this way?

Or failing that

How else can I manage multiple /etc/hosts entries with an ENC?

NB: These definitions are being used to quickly configure transient multi-node clusters on a cloud services API for development and testing purposes, so while I'm not wholly unwilling to explore a DNS-based (or other alternative) solution, managing /etc/hosts in this way (if possible) is a much simpler solution with far fewer moving parts.

SOLUTION: Posted here for reference is my final code:

class my_hosts(
  $hosts = {
    'localhost.localdomain' => {
      'ensure'       => 'present',
      'name'         => 'localhost.localdomain',
      'host_aliases' => 'localhost',
      'ip'           => '127.0.0.1',
    },
  },
  ) {

  create_resources host, $hosts

}

And then my ENC YAML looks like this:

classes:
  my_hosts:
    hosts:
      www1.example.com:
        ensure: present
        name: www1.example.com
        host_aliases: www1
        ip: 10.0.0.101
      www2.example.com:
        ensure: present
        name: www2.example.com
        host_aliases: www2
        ip: 10.0.0.102

I'm having trouble connecting to my remote host via SSH. I have narrowed the issue down to my local host only as other clients make nominal (fast and stable) connections every time.

Attempting to connect to remotehost.example.net from localhost via SSH will time out all but about 1 out of 10 attempts (it hangs here and then times out):

515 chris@localhost ~ $ ssh -vvv remotehost-root
OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/chris/.ssh/config
debug1: /home/chris/.ssh/config line 43: Applying options for remotehost-root
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotehost.example.net [123.123.123.123] port 12345.
^C

localhost is an up-to-date Arch system:

517 chris@localhost ~ $ uname -a
Linux localhost 3.12.1-1-ARCH #1 SMP PREEMPT Thu Nov 21 08:18:42 CET 2013 x86_64 GNU/Linux

And I'm using an SSH config file to alias remotehost as follows:

521 chris@localhost .ssh $ cat ~/.ssh/config
...
host remotehost-root
  HostName remotehost.example.net
  User root
  Port 12345
  IdentityFile ~/.ssh/remotehost-root.id_rsa
...

This is a recent problem, but unfortunately I don't recall making changes to anything relevant. I'm not sure what to check.

Maybe it's worth noting that this affects all SSH connections (such as git over ssh and SFTP) and not just the command line SSH tool.

I don't have any trouble accessing remotehost.example.net over any other protocol (e.g. HTTP, HTTPS, BitTorrent, etc).

The only active/uncommented line in /etc/ssh/ssh_config is:

ServerAliveInterval 120

Where else can I look? What other debug tools can I use (all I can think to do is run ssh -vvv)?

I tried running tcpdump on remotehost while attempting a connection, but couldn't figure out how to filter the packets from the shell running tcpdump thus infinite-loop spamming myself out of any useful diagnostics.

UPDATE 1: Worth noting that I've been able to duplicate this behavior on a second SSH host, as well as an IRC server, thus proving (in my mind) that this is an issue wholly within some config on my local host.

UPDATE 2: Also worth noting that while my localhost has trouble with these outbound connections, other clients (including on one, and one off, my LAN) have no issues whatsoever to any of the same remote hosts, or any other hosts. Again, leading me to believe that this is solely some config issue within localhost (but maybe I'm wrong?).

UPDATE 3: I have removed the openssh package (and configs) from localhost and reinstalled, to no avail.

I've got an Ubuntu (13.04) Desktop with ZFS support thanks to the PPA zfs-native/stable.

Everything was working really well. I created a RAID-Z1 pool called inground with the following command:

zpool create inground raidz1 sdb sdc sdd sde sdf

Later, after being unable to access the mount point I had created, I ran zpool status and nearly fell off my chair when I saw 1 unavailable and 2 corrupt vdevs in the pool. After a few deep breaths, I noticed that when I'd recently rebooted the system, I had a USD thumb drive in one of the front ports of my tower. This caused all of the /dev/sd* mappings to change, and everything made sense. I removed the USB drive, rebooted, and all was well.

My question is, how do I prevent this in the future? Is there a different, canonical, identifier I can use to refer to the physical drives when adding them as vdevs to the zpool?

I'm attempting to connect to a VPN (L2TP over IPsec) server through (not to) a WatchGuard XTM 505 appliance.

I have the VPN server setup behind the firewall on a 1-to-1 NAT, and other protocols (such as HTTP traffic) are forwarded to that server just fine. Also, VPN connections to the machine work perfectly from behind the firewall (i.e. from the LAN).

I've made "Enabled and Available" the following policies to the VPN server:

• L2TP (opens UDP 1701)
• IPsec (opens UDP 500, UDP 4500, AH and ESP)
• PPTP (opens TCP 1723 and GRE)

Yet whenever connecting from outside, I see the following logs from the XTM console:

2011-12-27 16:24:08 iked ******** RECV an IKE packet at 1.2.3.4:500(socket=11 ifIndex=4) from Peer 123.123.123.123:48165 ********   Debug
2011-12-27 16:24:08 iked IkeFindIsakmpPolicy: -->   Debug
2011-12-27 16:24:08 iked Failed to find phase 1 policy for peer IP 123.123.123.123      Debug
2011-12-27 16:24:08 iked IkeFindIsakmpPolicy: <--   Debug
2011-12-27 16:24:08 iked ike_process_pkt : IkeFindIsakmpPolicy failed       Debug

So it seems as if the Firebox is not forwarding this traffic to the 1-to-1 NAT as it should be; rather it seems to attempting to act as the VPN server itself, intercepting the IKE request (but failing because I haven't configured it for VPN).

What am I missing? Is there some setting to force the firewall to forward VPN connection attempts along the NAT? Do I have to pre configure some sort of tunnel between the firewall and the VPN server? Perhaps I need to add a static route of some sort?

I have a WatchGuard Firebox that I've recently configured. All of the policies look fine and all appropriate services seem to be working correctly.

However, one or two (seemingly) random nodes keep getting blocked from making HTTP requests to a 1:1 NATed host that everyone else makes just fine.

The firewall log tells me that tcp syn checking failed, and these requests use destination port 64 for clients behind the appliance, and port 50 for clients on the outside. I've finally found this option and disabled it under the Global Settings (which leaves a bad taste in my mouth), and that seems to have done the trick.

The documentation is uber thin on the topic, though. Can anyone explain to me exactly what tcp syn checking does/is, and how I might make an appropriate allowance for it in my policies rather than globally disabling it (assuming, of course, there is a more graceful solution than a global rule)?