May 2016 - Arch-devops - lists.archlinux.org

[arch-devops] Making our mailing lists DMARC/DKIM safe (drop subject prefix)
by Florian Pritz 28 May '16

28 May '16

Hi, First some background: DKIM allows a mail server to sign mails similar to GPG, except that the public key is distributed via DNS. DMARC allows a domain to define a policy (do nothing, quarantine or reject) for mails that do not possess a valid DKIM signature (modified content, spam mail without a sig, ..). DKIM signatures sign both, the body and the header of the mail. The header fields that are signed differ between setups, but generally it's at least From, To and Subject. Currently, most/all of our mailing lists prepend the listname to the subject, thus invalidating any DKIM signature. Some lists also add a footer to the body of the message (arch-events, possibly more). I propose that we configure our lists not to alter messages in any way so that existing DKIM signatures remain valid. This would mean that the list name will no longer be in the subject so everyone who currently uses that to filter list traffic would have to switch to using the List-ID header. This is also a much more reliable way to filter list traffic since sometimes mails have multiple tags in the subject if they are sent to multiple lists. Also private messages may still contain the subject tag even if they were never sent via the list. I don't see any benefit in having the listname in the subject since mails are generally filtered into dedicated mailboxes per list anyway. Changing the subject just means that when browsing that mailbox all subjects start with the same useless text. I know multiple lists that have already switched to keeping mails as-is. Among them are the bugtraq and cgit lists as well as some official and third-party dovecot and postfix related lists. If this proposal is accepted by us, I will send it out to all our lists with a 2 week lead time before I start changing anything so that people have a chance to update their filters if necessary. Opinions? PS: I'd prefer to keep discussion on arch-devops(a)lists.archlinux.org. I'm just posting this to arch-dev-public so all devs/TUs are aware of it. Florian

2 2

[arch-devops] Finally fixed DKIM (I hope)
by Florian Pritz 27 May '16

27 May '16

Hi, Turns out mailman was set to deliver mail to an smtpd without milter support enabled so opendkim didn't run and didn't sign any outgoing mails. I've fixed that now so all mails from senders with a DMARC policy should be changed to the list address as the From header and they should be correctly signed by our key. I've also noticed that some DKIM verification software (the thunderbird plugin) stores keys and does not update it's cache. Since the initial key was broken due to nameserver/webui problems, I've set up a new selector for each affected key. Sorry for bloating the zone file, but I think we should keep the old keys in there so that mails with the old selector can still be verified. If anyone notices any more broken DKIM sigs or other weirdness please tell me. Florian

1 0

[arch-devops] gnupg should not be updated on nymeria
by Pierre Schmitz 16 May '16

16 May '16

Hi all, I did not debug this yet, but be aware that updating gnupg to version 2.1.12 on nymeria will break dbscripts. See https://bugs.archlinux.org/task/49302 Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

2 2

[arch-devops] HTTP/2 on Luna
by Pierre Schmitz 16 May '16

16 May '16

Hi all, I'd like to enable h2 on luna. Are there any objections? I have done this on my server already and it's pretty straight forward. We might need to adjust the ssl_ciphers configuration. ATM I use: ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"; Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

3 3

[arch-devops] #archlinux-devops public now
by Florian Pritz 13 May '16

13 May '16

Hi, Just a quick note that our #archlinux-devops channel is now also public. It has been invite only previously, but since we aim to keep as much as possible of everything we do public we have decided that there is no need to keep the IRC channel private. Feel free to join if you are interested in how we run our infrastructure. PS: Any decisions or results of discussions will still be posted on this mailing list for archival reasons. Florian

1 0

[arch-devops] Changing the monitoring for new servers
by Sven-Hendrik Haase 12 May '16

12 May '16

As you probably have read, we're getting a new bunch of servers quite soon. I want to change our monitoring solution on those new servers as we are currently using munin but it has static graphs only and no notifications built-in. I think notifications would be helpful to have so that we're the first ones to know when a service is down or a server runs out of memory/storage. The alternatives that were mentioned are these: 1) munin for graphs, timed ansible for notifications 2) influxdb for storage, collectd for stats collection, graphite for graphs, timed ansible for notifications 3) zabbix (does everything) 4) cacti (does everything with plugins) 5) prometheus (does everything) My thoughts: 1) Basically the same of what we have now. Static daily/weekly/monthly/graphs only. On top of that, we'd use a systemd-timer unit for ansible I suppose. Munin generally is fairly easy to maintain and set up. 2) Four different programs to but each taking care of a certain task. I'm not sure this counts as complex or KISS. But really I have no idea about this stack as I have not worked with any element in it. 3) No idea about this one but it from a glance it looked rather complex and kind of icky to use. 4) I used this one once. It's a heavyduty PHP-based monitoring software that I probably wouldn't recommend. It was a bitch to set up and use when I tried it some years back. It might have improved. 5) This is the newcomer. Seems to be doing everything we'd need but I haven't checked it out in detail yet. Configuration format seems fairly easy and graphs are pretty. Might be worthwhile. Would be interested in hearing your thoughts. If you have something to add, just add numbered bullet points. If nothing comes of this, we'll probably go back to munin. Sven

4 4