[01:47] <CodeMouse92__> Anyone using OpenDKIM, I just wrote a script for my server that automates most of the key rotation process: https://github.com/CodeMouse92/dkim_manage
[01:48] <CodeMouse92__> Feedback welcome, of course
[01:52] <sarnold> CodeMouse92__: I recommend changing from mkdir -p $TEMP to using mktemp -d to create a random directory for your script to work in; otherwise you run the risk of other users on the system being able to read the keys or otherwise manipulate the script in unexpected ways; this can sometimes be leveraged to arbitrary code execution
[01:52] <CodeMouse92__> sarnold: While I see your point, note that $TEMP is used in multiple places
[01:52] <CodeMouse92__> How can I load that into the variable for reuse *across executions*?
[01:53] <sarnold> CodeMouse92__: it's not cleaned up once you're done? hrm. then maybe a /var/somethingorotherdkim would make more sense?
[01:54] <CodeMouse92__> sarnold: Makes sense. I'll change the default value in the script. Else, you're welcome to pull-request if you want credit
[01:54] <sarnold> CodeMouse92__: no need, thanks :)
[01:54] <sarnold> (or more accurately, no time.. sigh :)
[01:54] <CodeMouse92__> Heh
[01:54] <CodeMouse92__> Okay, well, I'll switch that now.
[02:35] <patdk-lap> I don't really get the point of the script
[02:35] <patdk-lap> the key needs to be published into dns before you start using it
[02:37] <sarnold> CodeMouse92__: ^^
[02:37] <CodeMouse92__> patdk-lap: There are a lot of other things that need to be done as well.
[02:38] <CodeMouse92__> And parsing out the DNS text record is anything but foolproof
[02:38] <patdk-lap> hmm, not that I am aware of
[02:38] <patdk-lap> I just make a new key, push it to dns
[02:38] <patdk-lap> then a week later update my mailserver to use it
[02:38] <patdk-lap> been that way for hmm, a decade?
[02:38] <CodeMouse92__> Maybe you're using a different platform. At least for me, on Linode, I have to generate the key, update the DNS record, wait for it to propegate, test the key, and then move the key into place and update key.table
[02:39] <patdk-lap> I do the same for my dane/tlsa certs
[02:39] <patdk-lap> not sure what linode has to do with it
[02:39] <patdk-lap> do they give you servers that don't operate like normal servers?
[02:39] <CodeMouse92__> Uhm, no. Seriously, you must have some really unusually advanced technology that all the docs don't know about
[02:40] <CodeMouse92__> because I've talked to at least four people today who work with this, and they all have to do the same stuff I do
[02:40] <patdk-lap> nope, it's pretty simple, and just takes a simple script like you have
[02:40] <patdk-lap> run script weekly
[02:40] <patdk-lap> generate new key, publish key using nsupdate
[02:40] <CodeMouse92__> Okay, we're not on the same page then. You don't update this cert weekly
[02:40] <patdk-lap> check if old key exists, move old key to production
[02:41] <CodeMouse92__> Yeah...you must be working with something else.
[02:41] <patdk-lap> why not?
[02:41] <CodeMouse92__> Read the docs
[02:41] <patdk-lap> dkim should be rotated often
[02:41] <patdk-lap> just like certificates
[02:41] <CodeMouse92__> Not *weekly*
[02:41] <CodeMouse92__> Shoot, not even Google does it weekly
[02:41] <patdk-lap> heh? why not?
[02:41] <patdk-lap> google NEVER rotated theirs
[02:41] <CodeMouse92__> It's designed to be a monthly thing.
[02:41] <patdk-lap> and used 512bits
[02:41] <CodeMouse92__> Anyway, whatever, we're not going anywhere.
[02:41] <patdk-lap> that is why we got into the whole dkim key length issue
[02:41] <CodeMouse92__> Glad you've got this all figured out, tell the world, I'm out of this convo now.
[02:41] <patdk-lap> it's designed to be however you want it to be :)
[02:42] <patdk-lap> they recommend *atleast*
[02:42] <patdk-lap> you can always do it more often
[02:42]  * CodeMouse92__ shrugs
[02:42] <CodeMouse92__> Ohhhhh, I think I know what's going on.
[02:42] <CodeMouse92__> Somehow you've configured this so you never actually update OpenDKIM's configuration files.
[02:42] <patdk-lap> since google is the one the screwed dkim in the first place with never rotating their 512bit key, and getting it compromised, I wouldn't point at them for how to do things right
[02:43] <CodeMouse92__> nsupdate is only for pushing to the DNS, but my script handles the *other stuff
[02:43] <patdk-lap> updating config files is risky
[02:43] <patdk-lap> why do you need to update the config file?
[02:43]  * CodeMouse92__ sighs deeply
[02:44] <CodeMouse92__> RTD, have a nice day.
[02:44] <patdk-lap> ok
[02:44] <patdk-lap> guess I will never know
[02:45] <sarnold> i'm so glad I don't manage an email server
[02:46] <patdk-lap> I still don't get why updating your rsa key weekly is a bad idea
[02:46] <sarnold> automation is king
[02:46] <sarnold> you test your script every week :)
[02:46] <patdk-lap> it's so much easier for me to script it weekly than monthly
[02:46] <sarnold> that sounds like a good way to catch errors
[02:46] <patdk-lap> and costs me nothing
[02:47] <patdk-lap> if I did monthly
[02:47] <patdk-lap> a new key would be pushed to dns to warm up a month ahead of usage
[02:47] <patdk-lap> then a month of usage, and a month of retirement
[02:47] <patdk-lap> weekly, it only has to stick around for 3 weeks
[02:50] <sarnold> patdk-lap: oh you know, maybe he uses a one-minute ttl or something, so he's not worried about hitting dkim fails?
[02:51] <patdk-lap> that wouldn't be an issue even if it was an hour
[02:51] <patdk-lap> the issue would be if your using dnssec
[02:51] <patdk-lap> and dns replication delays
[05:04] <sarnold> patdk-lap: hrm. I never think of dns propogation as being 'delayed' so much as free to hand out stale data until the ttl expires.. what am I missing?
[06:13] <lordievader> Good morning
[10:35] <patdk-lap> sarnold, dnssec signatures, the rr records are out of sync, causing the verification to fail
[10:36] <patdk-lap> without dnssec, it's just the non-existing entry ttl you really have to worry about, besides your name servers all getting in sync
[15:59] <rbasak> nacc: Skuggen says he'd like https://bugs.launchpad.net/ubuntu/+source/ruby-riddle/+bug/1686859/comments/7 sponsored. It's in my todo unless you get to it first.
[15:59] <nacc> rbasak: ack i'll do it next then
[16:00] <nacc> rbasak: so you cn remove from your todo :)
[16:00] <rbasak> Thanks :)
[16:00] <nacc> rbasak: thank you!
[16:01] <nacc> rbasak: i'm doing another transition (well, ready to upload, just testing it now) for dlm -> dlm_controld (dropping delta in 3 srcpkgs). Once I test those and these three php packages, i'm pivoting back to the importer and the namespaces
[16:01] <rbasak> ack
[16:34] <rbasak> nacc, cpaelzer_: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow step "git rebase -i old/debian" - any reason for the -i?
[16:34] <rbasak> Sorry
[16:34] <rbasak> I mean "git rebase -i new/debian"
[16:34] <rbasak> Step 3.1
[16:34] <nacc> rbasak: no, i suppose not
[16:35] <nacc> rbasak: it will fail or succeed regardless and it's always just p's
[16:35] <rbasak> Yeah. OK, I'll edit.
[16:35] <nacc> and on fail, regular rebase will drop you to the shell to fixup
[16:35] <nacc> rbasak: it so happens that in my case, i do use -i, because i know i want to drop some things )
[16:35] <nacc> :)
[16:37] <rbasak> nacc: also, I'm not sure the "git status --ignored" and "git commit --allow-empty" make sense. If a commit already applies exactly, git will just drop and and you won't know.
[16:37] <nacc> rbasak: sorry in which context
[16:37] <rbasak> nacc: git rebase new/debian
[16:37] <rbasak> of the logical.
[16:38] <nacc> rbasak: git-rebase stops you
[16:38] <nacc> rbasak: iirc?
[16:38] <rbasak> I didn't think it did. I could be wrong.
[16:38] <nacc> rbasak: i'm pretty sure it stopped me :)
[16:38] <nacc> rbasak: but i'd need to test it again to check
[16:38] <nacc> rbasak: if you tell git-rebase to p something over
[16:38] <nacc> and it cleanly no longer applies, then it will stop and tell you that you have a now-empty commit
[16:38] <nacc> that is the distinction between something becoming empty vs. picking an empty commit
[17:30] <compdoc> isnt a bbcmicrocomputer the Sinclair?
[17:34] <RoyK> ubunt on a 6205 would be rather hard
[17:42] <azeem> hey, I'm running Postgres on Pacemaker with trusty (14.04) and noticed that the resource-agents package does not seem to support the pacemaker version (1.1.10), is there some chance to get patches applied for that package?
[17:44] <nacc> azeem: what specifically happens?
[17:44] <nacc> azeem: but yes, patches can be applied, file a bug
[17:44] <nacc> !bug | azeem
[17:46] <azeem> nacc: it's not super bad, but the pgsql agent does not set the master-score for standbys and standbys think there is no master in some corner-cases
[17:46] <azeem> I'll file a bug
[17:47] <nacc> azeem: yeah, that's probably the correct first choice
[17:47] <nacc> azeem: is the bug fixed upstream / later versions of ubuntu?
[17:48] <azeem> yeah
[17:48] <azeem> but just backporting resource-agents won't work I think cause newer versions might also need a newer pacemaker
[17:53] <nacc> azeem: yes, it won't be a backport of a newer version
[17:53] <nacc> azeem: but the fix must already exist to sru it to older releases
[17:53] <nacc> !sru | azeem
[17:55] <azeem> ok thanks
[21:26] <beisner_> thedac, thanks;  celebrating a fixed false pass looks odd, but \o/ "Finished: FAILURE"
[21:26] <thedac> cool
[21:42] <beisner_> o/ thedac channels are hard sometimes.
[21:43] <thedac> :)
[23:17] <tomreyn> hmm, i have a trusty system where the unattended-upgrades package is installed. i just learnt that it stopped running updated roughly half a year ago. i cannot say why. /var/lib/apt/periodic/ was empty (no time stamp file), the configuration file is http://paste.ubuntu.com/24513841/
[23:18] <sarnold> tomreyn: eww
[23:18] <sarnold> tomreyn: does the mailx root thing work?
[23:19] <hallyn> scary
[23:24] <sarnold> tomreyn: does the mailx root thing work?
[23:25] <tomreyn> sarnold: i actually modified the 'Unattended-Upgrade::MailOnlyOnError "false";' line just now. it was saying "true" before
[23:25] <tomreyn> and the system was not rtrying to send mail
[23:25] <tomreyn> i assume that's what you mean by 'the mailx root thing'?
[23:26] <sarnold> tomreyn: just the comment near the 'root' line says it it expects mailx address to work
[23:26] <sarnold> tomreyn: so I thought it would be worth testing if 'mailx root' actually works
[23:27] <tomreyn> yes mailx is available and in the path
[23:28] <tomreyn> yes works
[23:28] <sarnold> okay
[23:28] <sarnold> good, but that was my only idea
[23:28] <sarnold> heh
[23:28] <tomreyn> thanks
[23:29] <tomreyn> this isn't the first system i have seen unattended-upgrade behave unreliably on, so i'm a little worried about it.
[23:30] <tomreyn> but it may be PEBKAC, you never know
[23:30] <sarnold> the fact that it stopped working six months back is troubling -- that's far enough back that you're unlikely to have logs that might help track it down
[23:30] <tomreyn> right, i don't have logs of the latest run
[23:31] <tomreyn> and the syslogs i have don't show that it was triggered
[23:32] <tomreyn> (but i'm not sure what i'd need to search for, apparently unattended upgrades themselves only report that they're run if in debug mode)
[23:32] <sarnold> does /var/log/dpkg.* have anything from the time preiod?
[23:34] <tomreyn> there's this huge gap in them between when it stopped working in dec 2016 and today where i triggered changes using apt.
[23:40] <tomreyn> i'll just keep an eye on it