[00:48] axw: hey there [00:49] axw: sinzui_ is having issues with your hp fix branch, seems to have a bad import [00:52] thumper: reading the email now [00:53] eh wtf [00:54] aw crap, I think I enabled goimports and it mucked about with the imports [00:55] heh [00:55] axw: so, after talking with fwereade this morning, I'm going to implement a system ssh key right now [00:55] thumper: excellent [00:56] * axw feels vindicated [00:56] ;) [00:56] davecheney: I don't suppose your ssh go stuff has keygen? [00:59] thumper: AFAIK they [00:59] are just PEM keys [01:00] axw: I'm not entirely sure what that means [01:01] thumper: same format used by the private keys we generate already [01:01] for mongo [01:01] oh? [01:01] hmm... [01:02] thumper: in fact, we could perhaps just use the same one [01:02] axw: maybe... [01:02] not sure what the requirements are for SSH [01:02] yeah, well luckily I have another machine here I can ssh to to test [01:03] thumper: it wouldn't be hard to write [01:04] davecheney: yeah, axw said as much [01:04] I think what I'd like is a function in utils/ssh called "GenerateKey" (surprise) [01:04] that generates to byte arrays, [01:05] one private key and one public key [01:05] equivalents of "id_rsa" and "id_rsa.pub" [01:05] given the core go team's affinity for crypto [01:05] chances are all I need is glue [01:06] yup [01:06] lemmie look in the ssh package tests [01:06] we probably have some code [01:07] davecheney: awesome sauce [01:07] * thumper channels fwereade [01:31] davecheney: found any? I've found some docs as to the file format, so could hack something up [01:31] davecheney: but you sould probably be saving me time [01:36] thumper: yup [01:36] looking after lunch [01:43] ok [01:43] ta [01:47] thumper: I'm just looking to see if we can reuse the existing private key we have [01:47] there's code in go.crypto/ssh to generate an authorized_keys line from an RSA public key [01:55] thumper: https://gist.github.com/axw/8016123 [01:56] axw: what about the identity file that you can hand off to ssh? [01:57] thumper: I just fed in the key we give to mongo, added the output of that program to ~/.ssh/authorized_keys, and used ssh -i local-private-key.pem [01:57] thumper: it's just the key file [01:57] axw: and that works? [01:57] yup [01:57] awesome! [01:58] axw: let me poke around in the code and see if I can get this working nicely... [01:59] axw: I think perhaps we should default to use the system key for 'juju ssh' [01:59] axw: that would make the windows code work nicer [01:59] axw: you are doing the ssh util work for windows yes? [02:01] thumper: I'm not so sure we should be passing that key around in the .jenv though, should we? [02:01] that would make it difficult to revoke access [02:01] axw: oh, interesting point [02:01] thumper: I will be working on making it work for windows, yes [02:02] hmm... [02:02] axw: so, what are your thoughts on that? [02:03] we want a system identity [02:03] and if we can use the same that we have for mongo, then that should be fine [02:03] but we still need something to watch bootstrap with [02:03] perhaps that is a different id? [02:03] thumper: sure, I just don't think we should carry it around outside the system; ideally we should dispose of it after bootstrap [02:04] from the client I mean [02:04] we want something that will work out of the box with windows users [02:04] axw: but I think we should create a default user key... [02:04] or... [02:05] perhaps we just create the default user key if there is no local one found [02:05] and that is a separate issue [02:05] from the bootstrap issue [02:05] thumper: yeah I see your point. I guess we do want another one [02:05] we want the system one to be different to the default one used by the CLI [02:05] ok, my branch will work to make this system identiy [02:05] work [02:05] because of revocation [02:06] sounds good [02:06] axw: yes agree to that last statement [02:07] thumper: I think bootstrap can just create another key if it doesn't have one [02:07] for the CLI [02:07] * thumper nods [02:07] axw: that is a separate bit of work though [02:07] thumper: yes, I can do that later [02:07] lets go with the system identity, and using that for the bootstrap [02:07] ... [02:15] thumper: what about CLI users other than the bootstrapper? [02:16] not sure yet [02:16] I'm actually trying to find the code where it loads the authorized keys [02:16] the code I'm reading seems to indicate that it doesn't bother [02:16] unless I set them explicitly [02:16] but I know this is wrong... [02:18] ugh [02:18] an OR [02:19] thumper: maybe just updated environs.BootstrapContext to add the key to whatever's computed? [02:30] axw: is the ca-private-key the thing we use to talk to mongo? [02:30] axw: if so, that is in the .jenv file in the bootstrap config [02:30] so perhaps we do want a different identity? [02:30] something that gets generated and written to cloud init, but not on the client side [02:30] thumper: it is in there, but I think fwereade wants it out [02:31] thumper: and yes that's what we use for mongo [02:31] ah, fair call [02:31] * thumper goes to make coffee [02:31] this takes more thinking than I thought :) [02:31] the identity stuff that is [02:31] not the making coffee [02:31] hehe [02:32] not enough coffee makes making coffee more difficult [03:39] * axw -> lunch [03:48] wrt to put charm api, it appears to be unconditionally setting the scheme to local, deploy cli landing should resolve [04:28] axw: are you good with me updating our go.crypto to tip? [04:29] also, how do I find the full hash of an hg tip revision? [04:51] axw: in the end, I have gone with a ssh.GenerateKey function [04:51] axw: I'm going to poke things tomorrow and test [04:51] but for today, I'm done [04:51] night all === axw_ is now known as axw [07:33] jam: I *think* the streams.canonical.com URL it's going to is correct, but what's there at the moment is in the wrong place [07:34] axw: that's sort of what I expect as well, and we don't really want to be using it anyway [07:34] that's the impression I got from wallyworld [07:34] the bigger question is what else did we try (and fail) and why [07:34] yep [07:34] and they don't want to use --debug because of security purposes, but that's where we dump all the URLs we try [07:35] It'd be good to see that in "verbose output" (that never got landed did it?) [07:35] thumper's stuff [07:36] verbose was never intended to dump step-by-step stuff,(I think) I think it was meant to stay in --debug, we just dump other useful but-maybe-dangerous stuff there. [07:36] when I'm bootstrapping without --debug, it can sit there doing image/tools stuff for a fair while without any feedback [07:36] --verbose is more about user info about what we're doing [07:37] yeah I suppose that is a bit too much info for general consumption [07:38] I think we also have a bug that we don't write the debug information for the one that actually worked :) [07:39] heh [07:40] mornin' all [07:40] hey rogpeppe1 [07:41] axw: sorry i didn't manage to do your review yesterday - am looking at it now [07:41] rogpeppe1: nps, thanks. actually it gave me time to make it a bit nicer :) [07:41] axw: my first thought when i looked at it was that it could probably be factored out into a separate little type [08:06] rogpeppe1, jam, https://codereview.appspot.com/38540044/ if you can please [08:12] dimitern: will do [08:12] ta! [08:17] rogpeppe1: do we need go.crypto pinned at the rev it's at? [08:17] rogpeppe1: thumper's doing some SSH key stuff and was wondering if we can move to the tip [08:18] axw: not as far as i'm aware [08:18] axw: it would be good to try tip [08:18] ok [08:18] axw: but it may not be possible [08:18] axw: it might have some go1.2 deps [08:18] yeah ok, will have to check that [08:18] thanks [08:18] axw: so... do you know why we need a juju-run process to be running if we are just ssh'ing into each machine anyway? [08:19] jam: I was under the impression it was not long running [08:19] * axw re-reads thumper's email [08:19] axw: tim's statement was that it couldn't be the existing code because the existing stuff wasn't long lived [08:19] at least, I thought I remembered seeing that [08:20] jam: are you referrng to this statement? `"juju run" is really syntactic sugar around "juju ssh" and the server [08:20] component "juju-run" that does the execution inside a hook context.` [08:21] axw: so I know Tim has a Runner object that sits on a port and lets hooks fire queries into it (the way the current one does, but apparently somehow different) [08:22] it might be that we "juju ssh" into each machine, fire up that juju-run process, and then have it (or something else) spawn of clients that run the script you wrote. [08:22] I'm not sure how it actually all ties together. [08:22] it sounded ilke you ssh in to poke the juju-run process [08:22] but it might be that you are doing "juju ssh juju-run myscript.bash" [08:22] well [08:23] for i in ???; do juju ssh $i juju ssh /usr/bin/juju-run myscript.bash; done [08:23] jam: are there some design docs for juju-run somewhere? [08:23] jam: sorry, I haven't actually looked at the code yet - not entirely sure. that's not how I thought it worked. what I thought was that you ssh'd in, then ran "juju-run ", and was executed within the hook context [08:24] * axw looks at code [08:25] jam: so, I have only taken a very brief look, but it looks to me that the runner/socket is just for that process [08:25] it's just reusing the existing jujuc code [08:26] hrm, or maybe not [08:29] axw: related code, but definitely a different object [08:30] can anyone look at: https://codereview.appspot.com/40670043/ its been sitting for a week now [08:31] jam: I see; in that case, I'm not sure why SSH is required here. [08:31] there's still the machine case, but that's a bit different anyway [08:31] jam: I'll take a look [08:34] jam: re the juju-run stuff: how else would you do it? you'd need to put something in state, right? and then record the results there? [08:42] rogpeppe1, is it good to land? [08:42] dimitern: sorry, still reviewing axw's [08:43] rogpeppe1, ok [08:53] axw: so it depends what you want as a result. If you're meant to just trigger a script to run, yes. If you're meant to end up in an interactive session on the remote machine, then you'd have to ssh [08:54] axw: an open question, is this intended to run sequentially on all machines, or would all machines fire up at the same time [08:54] if parallel, then interactive session (or even printing to the screen) is pretty useless [08:54] if sequential, then this really scales poorly when you have 100s of machines [08:55] jam: my understanding is it's meant to be parallel and non-interactive, but I'm not 100% sure [08:55] fwereade: hah, good point about the nonces [08:56] fwereade: yes, pretty certain it was always "manual:..." [08:56] I will double check before basing anything on that tho [08:56] axw, cool, thanks [08:56] axw, I'm just on destroy-environment at last, sorry delay [08:57] fwereade: cool [08:58] axw: if non-interactive, then it seems like you *don't* want to ssh into each one. (you don't really want to fire off 100 ssh connections all at once, either) [09:00] btw, hi fwereade [09:00] jam, heyhey [09:01] axw: you have a review [09:01] rogpeppe1: thanks [09:02] jam, axw: `juju run` is non-interactive, there's juju ssh for direct interactivity [09:02] right [09:03] jam, axw: the actual degree of parallelism required has not been specified, but a number of ideas have been floated around the concept [09:03] fwereade: so some review questions... Do we want to have 'remove-machine' in a 1.16 branch? It has been approved, but it is more of a do-we-want-this-policy [09:04] jam, axw: round-robin has been mentioned; parallel has been mentioned; parallel with horrid hacked-on interactivity has ever come up [09:05] jam, what do we gain from a new 1.16 with that in? [09:05] fwereade: or it could be driven from the db without ssh at all? [09:05] fwereade: compatibility, especially with docs [09:05] though you still have "you must have newer than X" [09:06] but it would make "remove-machine" available in a stable release [09:07] jam: the only thing I see being an issue with going through the db is that there's no ephemeral node support to handle the edge cases around client termination [09:07] jam: it's not interactive, but there's still a session to maintain [09:09] rogpeppe1: "This should probably allow itself to be stopped when closed.j" -- do you mean use an additional select with a time.After? [09:09] axw: yeah [09:09] thanks [09:10] axw: I don't quite see how it is different from how we fire hooks normally, it is just a custom script instead of a charm hook [09:10] dimitern: reviewed [09:10] rogpeppe1, thank [09:10] s [09:10] jam: the main difference is that the result needs to live somewhere. who owns that? [09:12] jam, sorry, I missed the context on remove-machine [09:13] jam, did you have any thoughts re the more human vocabulary I handwaved around in that thread yesterday? [09:13] axw: seems easy enough to put it into the DB as a result of running the request [09:14] jam, axw: questions of how much we store and for how long become interesting [09:14] fwereade: so, there was a discussion that we should use "remove-*" for stuff instead of "destroy-*" and it is easy to add those aliases into a 1.16 release. I have a fairly trivial patch up, just waiting on whether we *want* to do it. Its approved, but I wanted to run it by you. [09:14] jam, so, indeed, I think I am now up to speed on it [09:14] fwereade: as for your natural language stuff, I think you had interesting points, but part of that is what we can evolve into, and we can have a consistent lower level terminology [09:15] fwereade: for juju-run, if you aggregate the results somewhere (like the DB) then you do need a way to see it (is the suggestion that normally it just prints to your console via ssh?) that still seems like a whole lot of spam unless you very carefully craft the script to give enough context so you can figure out which machine actually "failed" [09:16] so either, there isn't much result, so it doesn't matter, or there is some result, but you'd really rather have that logged and aggregated [09:16] you *can* do "juju run foo.sh >aggregate.this.txt" [09:42] jam, fwereade: is there a design doc for juju-run? i'd like to contribute to the discussion, but i don't actually know what the goals are. [10:23] rogpeppe1: updated [10:26] axw: re: "shouldn't this use the mutex?" [10:26] axw: it looks to me as if inst.InstanceId is inside the embedded ec2.Instance [10:26] axw: and hence should be protected by the same mutex [10:26] rogpeppe1: gah, so it is [10:27] rogpeppe1: sorry, will fix it now [10:27] axw: thanks [10:29] rogpeppe1: I don't know of one, but tim is the one driving it [10:38] rogpeppe1: updated again, sorry about that [10:38] axw: np [10:41] bbl [10:45] rogpeppe1: axw, mgz_: standup [10:45] https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig [12:38] fwereade: poke about where to put worker/provisioner/authentication.go [12:41] jam, how do you feel about environs? [12:42] fwereade: so "NewAPIAuthenticator" doesn't feel like it should be in environs [12:42] and NewEnvironAuthenticator feels ok there [12:43] the issue is that they both want to share the actual underlying implementation [12:43] jam, well, it's about giving access to a environ [12:43] which just has a way to get a StateInfo and then populate it with its final machine password stuff [12:43] jam, I'm at least halfway inclined to just give it its own package somewhere [12:44] jam, the only thing I'm sure of is that it's not exclusive to worker/provisioner, but it is something to do with setting up instances [12:44] fwereade: arguably the simpleAuth code should be exposed in state/ and the others lay on top of that? [12:44] jam, state doesn't seem very correct, in every case but bootstrap I think it's api-ey really [12:47] well, the api server uses it internally [12:47] which is why NewEnviron* is still necessary [12:57] natefinch, https://codereview.appspot.com/36290043/patch/190001/200015 is going to collide with you, isn't it? [13:05] fwereade, ish. Shouldn't be a big deal. === gary_poster|away is now known as gary_poster [13:18] fwereade, jam I still can't reproduce the problem in https://code.launchpad.net/~mattyw/juju-core/add-owner-to-service/+merge/191192. I sometimes see Error: Test left sockets in a dirty state but no other errors (although that happens on trunk as well - has done for a while) [13:19] ^^ any idea what might be going wrong? [13:19] mattyw: we've had some issues with flaky tests, I just wanted to know if this was caused by your change. As it doesn't seem related, I'll just submit again. [13:20] fwereade: when are we running mongo without ssl? [13:20] jam, ok thanks - I'll keep an eye on it [14:01] man, this USB ethernet adapter crashing my laptop is not cool (especially given there is no ethernet plug on the laptop)..... [14:02] anyway, I have to go snowblow my driveway, which will probably take me a couple hours all told. [14:03] jam, rogpeppe1: I verified that the test failure I'm having definitely is only happening with mongo 2.2, and not 2.4. Not sure exactly why yet, but now that I can A/B test easily, I should be able to figure it out. === natefinch is now known as n8f-snowblow [14:06] jam, sorry I missed you -- it's for the store... but I am suddenly suspicious of the Right Thing to do there [14:06] jam, I think it's probably better to factor out the existing store test harness and use that [14:07] jam, than to introduce a fresh entanglement between the two [14:20] wow, my internet is super flaky today [14:20] can anyone see this? [14:28] rogpeppe1, I can [14:29] mattyw: ok, that's something at least :-) [14:29] rogpeppe1, also - I'm getting a "x509: certificate is valid for *" error when trying to connect to the core api on 17070 (it seems to happend in my call to websocket.Dial) [14:30] is there a particular version of websocket I should be using do you think? [14:30] mattyw: could you paste the code that you're using to dial? [14:30] mattyw: in general, you should be using the state/api package to connect to the API [14:30] mattyw: (assuming you're using Go) [14:31] rogpeppe1, I am, I was just kinda messing around with connecting to the websocket in go [14:32] mattyw: you can connect if you use InsecureSkipVerify [14:32] rogpeppe1, ws, err := websocket.Dial("wss:/adr:17070", "", "http://localhost") [14:33] ah, I'm not doing any tls at all [14:33] mattyw: otherwise your client won't know about the root CA cert that's used for the server [14:33] mattyw: you *are* doing tls [14:33] mattyw: that's the "wss:" thing [14:33] rogpeppe1, but I'm not setting up any tls config [14:34] mattyw: ah yes. [14:34] (which is what I meant in my head at least :)) [14:34] mattyw: look at how it's done in state/api/apiclient.go:/Open [14:34] rogpeppe1, will do, thanks again [14:35] rogpeppe1: https://codereview.appspot.com/43650045 exercises the Addresses/Refresh code in provider/ec2 [14:35] axw: looking [14:35] rogpeppe1: I updated provider/ec2 again, there was a bug [14:35] rogpeppe1, thanks for the acme-friendly shortcut ;) [14:36] mattyw: are you using acme now? [14:38] axw: what was the bug? [14:40] rogpeppe1: Addresses was holding the lock around refresh(), which called inst.Id() and took the lock [14:40] well, tried to [14:41] so, deadlock [14:41] axw: ah, good thing i suggested the test then :-) [14:41] very [14:43] axw: i still think we should use AddScripts rather than AddFile - someone might change AddFile to use the cloudinit write_files feature, which would then potentially break the nonce.txt logic [14:43] rogpeppe1: fair point [14:43] ok, I'll change it [14:43] axw: thanks [14:43] * rogpeppe1 goes for lunch [14:55] hazmat, re mongodb build without scripting - which scons option are you referring to? I can toggle between v8 and spidermonkey in our current source package (2.4.8) but I can't figure out how to disable it completely [14:55] rogpeppe1: can you please approve the ec2test MP when you're back? I'm not in the group [14:56] jamespage, usev8 [14:56] rogpeppe1: and/or merge it if there's no bot [14:56] jamespage, https://github.com/mongodb/mongo/blob/master/SConstruct#L452 [14:57] jamespage, it comes up a few times.. agreed its not clear if its toggle for spidermonkey or disable [14:57] hazmat, it certainly was [14:57] but upstream don't ship spidermonkey any longer [14:57] "--usesm" [14:59] jamespage, so reaching out to upstream sounds like the thing to do.. i don't see the usesm option in trunk scons. [14:59] either that or trying a build without the v8 option [14:59] hazmat, no its gone [14:59] hazmat, if you don't specify it default to v8 [14:59] I'll poke at it a bit [14:59] * hazmat fires up a build on a spare server [15:30] jam, rogpeppe1, https://codereview.appspot.com/43860043 AddCharm via the API [15:35] fwereade: the nonce for manual bootstrap nodes does not start with "manual:". do you think it's still okay to use it, documenting that? [15:36] niemeyer: does this look reasonable to you? https://codereview.appspot.com/43650045/ [15:37] fwereade: that case *could* be detected by checking that id == "0" && extracting the provider type from EnvironConfig, but that's pretty heavy handed [15:37] axw, hmm, possibly, I don't suppose that one has any useful distinguishing features? [15:37] fwereade: not that I've thought of so far [15:37] rogpeppe1: What happens in practice? [15:37] rogpeppe1: I mean, what is the real EC2 doing about this? [15:37] niemeyer: the DNS name appears some time after the instance has been started [15:38] fwereade: its instance-id is "manual:", but we've established that's not good enough to rely on [15:38] niemeyer: so any realistic client will need to poll it [15:38] rogpeppe1: Sounds good then [15:38] niemeyer: cool, thanks [15:38] rogpeppe1: np, thanks for asking [15:39] axw: will submit now [15:39] axw, you know, I'm not so bothered by the weight as I am by the correctness [15:39] axw, it's not a cost we'll be paying often enough to worry about, I think [15:39] rogpeppe1: thanks [15:40] fwereade: true [15:40] fwereade: in fact, I won't even be passing it in in my case, because I don't check manager machines === mgz_ is now known as mgz [15:40] axw, thought that might be the case [15:41] fwereade: so, now might be a good time to change the provider name from "null" to "manual" [15:41] axw, please still test that behaviour in case we do ever end up with demoted machine 0s ;) [15:41] certainly [15:41] axw, most certainly, but I suspect that may take some finessing around upgrades [15:42] axw, *maybe* you could get away with registering the same provider twice under different names..? [15:43] hmm maybe, will have to see. I can make this code check for either "null" or "manual" for now [15:47] axw: FYI i just got this error when bootstrapping: [15:47] Connection to ec2-54-196-224-38.compute-1.amazonaws.com closed. [15:47] error: cannot open state: cannot create log collection: unauthorized mongo access: unauthorized [15:47] axw: i haven't looked into it but i suspect something is trying to talk to mongo before it's ready [15:49] rogpeppe1: hmm, there's no changes regarding mongo communications in synchronous bootstrap [15:50] rogpeppe1: are you on trunk? [15:50] axw: yeah [15:51] rogpeppe1: with my just-merged branch? [15:51] I'll test it again [15:51] axw: hmm, not sure [15:51] rogpeppe1: shouldn't actually matter, just curious [15:51] axw: it's the kind of thing that wouldn't happen very often, if it's what i suspect [15:52] axw: i'll see if it happens again [15:53] axw: your goamz branch is now merged [15:53] rogpeppe1: great, thanks [15:54] rogpeppe1: ah, I should've updated dependencies.tsv... will do that now [15:54] axw: good point [15:54] axw: revno 44 [15:54] thanks === n8f-snowblow is now known as natefinch [15:56] axw: ah, it's not bootstrap's fault at all [15:56] axw: i just wasn't printing enough log messages [15:57] rogpeppe1: thanks for checking [15:59] * rogpeppe1 reboots [16:10] night all [16:14] natefinch, ping [16:14] natefinch, can you take a look at this please? since roger is not around. https://codereview.appspot.com/43860043 [16:22] dimitern, sure === BradCrittenden is now known as bac [16:47] fwereade, I guess we should have a chat about the next stage of the juju id stuff [17:14] dimitern, can we put Info in the charm.Repository interface? I'd much prefer that than doing some casting to anonymous interfaces to access that method. [17:19] natefinch, actually, I wasn't sure about using Info() or maybe just lazy not to calculate the sha256 from the already downloaded file [17:20] natefinch, i'll change that to use only Get and read and calculate the hash from the downloaded charm [17:21] that also works === alexlist` is now known as alexlist [18:36] dimitern: you've got a review [18:36] natefinch, dimitern: i made an alternative suggestion [18:36] natefinch, dimitern: which hopefully works out a bit simpler than calculating the hash yourself [19:01] * rogpeppe is done for the day [19:04] darn juju-restore is destroying its own re-bootstrapped machine [19:04] g'night all [19:29] thumper, morning [19:29] o/ natefinch [19:29] * thumper trawls through the overnight emails [20:26] thumper, how's your knowledge of mongo? [20:27] natefinch: virtually non-existent [20:27] thumper, heh. My HA tests are failing on 2.2 but passing on 2.4.... and I can't figure out why. [20:40] hmm... trying to bootstrap ec2 failed with an error around simple streams [20:40] WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju [20:40] ERROR bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9: element

closed by [20:56] thumper sounds like you might be getting a 404 not found page instead of the XML you're supposed to get, and it's trying to parse the page's HTML [20:56] natefinch: that's what I thought too [20:56] but since I actually needed to upload tools [20:56] it was a convenient error [20:57] heh [20:57] thumper, it does worry me that we're not checking the http error code before trying to parse what's returned, though [20:58] heh [20:58] yeah [20:59] should file a bug [20:59] I'm now confused... [20:59] with my work [21:01] WTF! [21:01] natefinch: hangout? [21:01] it might help if I talk this through [21:03] sure... one sec [21:05] natefinch: I worked it out :) [21:05] thumper, ha, ok, cool [21:05] dumb permissions... [21:06] thumper, heh, something like that happened when I was building mongo from source yesterday. 30 minute build, fails at the very end with a permissions issue. [21:06] I have code that now creates a juju system ssh identity file and adds to the authorized keys [21:06]