| 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:47 |
|---|---|---|
| CodeMouse92__ | Feedback welcome, of course | 01:48 |
| 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:52 |
| sarnold | CodeMouse92__: it's not cleaned up once you're done? hrm. then maybe a /var/somethingorotherdkim would make more sense? | 01:53 |
| 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. | 01:54 |
| 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:35 |
| sarnold | CodeMouse92__: ^^ | 02:37 |
| CodeMouse92__ | patdk-lap: There are a lot of other things that need to be done as well. | 02:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 | |
| CodeMouse92__ | RTD, have a nice day. | 02:44 |
| patdk-lap | ok | 02:44 |
| patdk-lap | guess I will never know | 02:44 |
| sarnold | i'm so glad I don't manage an email server | 02:45 |
| 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:46 |
| 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:47 |
| 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:50 |
| 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 | 02:51 |
| === xibalba_ is now known as xibalba | ||
| === led2 is now known as led1 | ||
| === KaeltenAway is now known as Kaelten | ||
| 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? | 05:04 |
| lordievader | Good morning | 06:13 |
| === chmurifree is now known as chmuri | ||
| patdk-lap | sarnold, dnssec signatures, the rr records are out of sync, causing the verification to fail | 10:35 |
| 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 | 10:36 |
| === skylite_ is now known as skylite | ||
| === skorv is now known as Guest20674 | ||
| 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 |
| ubottu | Launchpad bug 1686859 in ruby-riddle (Ubuntu) "ruby-riddle tests start mysql server with unknown option --force" [Undecided,New] | 15:59 |
| nacc | rbasak: ack i'll do it next then | 15:59 |
| nacc | rbasak: so you cn remove from your todo :) | 16:00 |
| rbasak | Thanks :) | 16:00 |
| nacc | rbasak: thank you! | 16:00 |
| 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:01 |
| 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:34 |
| 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:35 |
| 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:37 |
| 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 | 16:38 |
| === daniel1 is now known as Odd_Bloke | ||
| compdoc | isnt a bbcmicrocomputer the Sinclair? | 17:30 |
| RoyK | ubunt on a 6205 would be rather hard | 17:34 |
| 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:42 |
| nacc | azeem: what specifically happens? | 17:44 |
| nacc | azeem: but yes, patches can be applied, file a bug | 17:44 |
| nacc | !bug | azeem | 17:44 |
| ubottu | azeem: If you find a bug in Ubuntu or any of its derivatives, please report it using the command « ubuntu-bug <package> » - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs. | 17:44 |
| 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:46 |
| nacc | azeem: yeah, that's probably the correct first choice | 17:47 |
| nacc | azeem: is the bug fixed upstream / later versions of ubuntu? | 17:47 |
| 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:48 |
| 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:53 |
| ubottu | azeem: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 17:53 |
| azeem | ok thanks | 17:55 |
| === JanC is now known as Guest75375 | ||
| === JanC_ is now known as JanC | ||
| beisner_ | thedac, thanks; celebrating a fixed false pass looks odd, but \o/ "Finished: FAILURE" | 21:26 |
| thedac | cool | 21:26 |
| beisner_ | o/ thedac channels are hard sometimes. | 21:42 |
| thedac | :) | 21:43 |
| 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:17 |
| sarnold | tomreyn: eww | 23:18 |
| sarnold | tomreyn: does the mailx root thing work? | 23:18 |
| hallyn | scary | 23:19 |
| sarnold | tomreyn: does the mailx root thing work? | 23:24 |
| 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:25 |
| 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:26 |
| tomreyn | yes mailx is available and in the path | 23:27 |
| 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:28 |
| tomreyn | this isn't the first system i have seen unattended-upgrade behave unreliably on, so i'm a little worried about it. | 23:29 |
| 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:30 |
| tomreyn | and the syslogs i have don't show that it was triggered | 23:31 |
| 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:32 |
| 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:34 |
| tomreyn | i'll just keep an eye on it | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!