[00:26] hatch: which fix? [00:26] hatch: although probably not [00:27] hatch: you can probably expect a 1.18 soonish [00:27] thumper there was one related to mongodb that was fixed but not sure if it was going in 16 or 18 [00:27] yeah, not sure sorry [00:27] axw may know when he gets online [00:33] no problem thanks though [01:03] thumper: meeting? [01:03] oh yeah... [01:04] wallyworld: my popup reminder conveniently ended up behind emacs [01:27] come on, surely emacs will do reminders :P [01:48] rick_h__: probably, but it isn't hooked up to my google calendar! [02:13] axw: sorted out the screen issue? [02:13] thumper: all sorted [02:13] sorry I'm late, will make it up later [02:13] thumper: I got my new laptop - thought I had it sorted last night :/ [02:14] what's the new laptop? [02:14] xps 15 [02:14] nice? [02:14] with the high res screen? [02:14] thumper: yup, the one I just turned down to 1080p because I can hardly read anything :( [02:15] I have some dude taking out my power meter and replacing it with a smart meter [02:15] no power in the house [02:15] at 3200x1800 that is [02:15] so on battery and using mobile 3G [02:15] wow, that is good [02:15] how's the battery? [02:15] and how heavy? [02:16] thumper: dunno yet, hardly used it - just been frigging around getting my preferred OS on it ;) [02:16] ~2kg [02:16] heh [02:16] I'm curious to know when you have hammered it a bit [02:16] I'll let you know when I do :) [02:17] the keyboard is a bit puny compared to what I'm used to [02:17] getting used to it though === ray is now known as rawang [03:40] <_thumper_> bugger! === _thumper_ is now known as thumper [03:45] thumper, wallyworld: is there a reason why we don't generate new SSH keys for environments? [03:46] axw: we use the ssh key of the user who created the environment [03:46] i guess that was deemed sufficient [03:46] wallyworld: yeah I know that's what we do now, just wondering why we shouldn't just create a new key [03:46] mmk [03:46] not sure, that design decision was way before my time [03:46] nps [03:48] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1257371/comments/9 [03:48] <_mup_> Bug #1257371: bootstrap fails because Permission denied (publickey)

[03:48] some people might not have a default ssh key, which buggers things up - that's why I ask [03:50] ah, just read the bug [03:50] i can see why we don't generate a new key [03:50] s/dont't/ might not want to [03:50] it would be another key to manage [03:51] when we could just add existing user keys (or import using ssh-import-id) [03:51] but if a user doesn't have a key already.... [03:52] axw: are you adding code to allow a key to be specified if not in ~/.ssh/id_rsa.pub? [03:52] wallyworld: just considering options atm [03:53] ok [03:53] wallyworld: that's one option, or there's the option of generating one automatically [03:53] or both [03:53] generating one would be more user/bot friendly [03:53] yeah that's what I'm thinking [03:54] i'd +1 that approach :-) [03:54] maybe run it by jam or william as well [03:55] yeah, I'll just send an email to juju-dev now [03:59] wallyworld: http://pastebin.ubuntu.com/6523153/ [03:59] wallyworld: and I logged in and checked, and it did indeed have 4G of disk, 1G of ram and 2 cores\ [03:59] \o/ [03:59] \o/ [03:59] awesome [03:59] * thumper proposes [04:11] wallyworld: https://codereview.appspot.com/37610043 [04:11] * thumper goes to write some emails [04:11] * wallyworld looks [04:23] * wallyworld ->doctor, bbiab [06:33] doh [06:33] so close [06:33] lucky(~/src/launchpad.net/juju-core) % juju ssh 0 [06:33] WARNING discarding API open error: [06:33] ERROR environment has no access-key or secret-key [06:33] ^ what does this mean [06:33] any ideas ? [06:45] axw: thanks for the tip [06:45] that fixed it [06:45] davecheney: cool [06:45] seems to me it's another win for using gc-built jujud [06:46] the size, that is [06:47] axw: oh, i'm not passing -Os [06:47] maybe that would help [06:47] davecheney: maybe at the expense of performance [06:48] man, even with sync bootstrap juju deploy the first time is still very slow [06:48] ie, i type juju depoy mysql m1 [06:48] and it still took 2 minutes to return and tell me i spelt the command wrong [06:50] huh. I didn't think it did much before parsing the command line... [06:50] i think we still connect to the state too early in the subcommand [06:52] axw: brace yourself [06:52] lucky(~/src/launchpad.net/juju-core) % ls -alh ~/bin/juju{,d} [06:52] -rwxr-xr-x 1 dfc dfc 36M Dec 5 17:21 /home/dfc/bin/juju [06:52] -rwxr-xr-x 1 dfc dfc 40M Dec 5 17:21 /home/dfc/bin/jujud [06:52] :o [06:59] ding ding ding! [06:59] http://ec2-54-253-189-54.ap-southeast-2.compute.amazonaws.com/wp-admin/install.php [06:59] very nice :) [07:00] if only it wasn't wordpress [07:00] we're not allowed to mention wordpress === dspiteri is now known as darrenS === darrenS is now known as DarrenS === rogpeppe1 is now known as rogpeppe [08:39] mornin' all [08:40] morning! [08:41] we should decide what to do about putcharm today [08:41] otherwise the discussion can drag on too long [09:28] fwereade_, i'm not sure i understand the icon question for local charms [09:28] fwereade_, why do we need GET support? [09:29] dimitern, ah sorry -- did the mail I forwarded lack the original context? [09:29] fwereade_, the context is there, but I still have no clue how to do that [09:29] fwereade_, I don't know how it works with the charmworld now [09:30] dimitern, I think the charmworld bit is a red herring tbh [09:30] fwereade_, can the icon be part of the charm package? [09:30] dimitern, the question is maybe best phrased as "can we somehow serve individual charm files to authenticated clients" [09:31] dimitern, yeah, icon.svg [09:31] fwereade_, hmm.. [09:31] fwereade_, i suppose, if we duplicate part of charmworld in the api server yes [09:32] dimitern, if we do go through an unpack/repack step for every local charm we do at least have all that data available somehwere already, and it'd just a matter of putting it in the right place [09:32] fwereade_, we can have GET /charms/xyz/icon.svg [09:32] dimitern, and I don't think we need to worry about store charms so much because they can already get the data from elsewhere [09:33] dimitern, although it would probably be best to make this functionality available for allcharms [09:33] fwereade_, i was thinking of removing the data after repackaging - why bother - it's already in the provider storage [09:33] fwereade_, so it gets hairer by the minute :) [09:34] fwereade_, proxy any charm files from the provider storage or charm store through the api [09:34] dimitern: hey, when do you go on leave? [09:35] fwereade_, this seems like a potential DDOS target - pinging the api server with random urls of valid charm, just so it has to fetch and unpack them [09:35] thumper, hey, on 23rd [09:35] dimitern, well we *do* want charm access to be authenticated [09:35] dimitern: ah, for some reason canonical admin is all fubared [09:35] dimitern: how's the upload charm stuff going? [09:35] dimitern, we dropped the ball on that because signed urls are an openstack extension iirc [09:35] thumper, oh? it was looking fine last time i looked [09:36] dimitern: I'm not surprised it is screwed, it was mramm that told me [09:36] fwereade_, nevertheless it's a ddos target of a sort - an authenticated client written badly can bring down the api server like that perhaps [09:36] dimitern, but we ought to be clawing it back if possible -- in general we shouldn't just be making the contents of environment storage available to anyone who asks [09:37] dimitern, more so than *any* endpoint? [09:37] dimitern, if we're ok with one-time tokens for PUTs, we could surely do the same with GETs [09:37] fwereade_, well, a bit more so, because it requires some busy work of fetching and unpacking a charm just to serve a file [09:38] fwereade_, i'm not sure what approach did we decide to pick [09:38] dimitern, quite, we should definitely not do that [09:38] dimitern, and your work maybe involves extracting all the charm files anyway [09:38] dimitern, hence the potential connection in my mind [09:38] fwereade_, if we need the get stuff, rogpeppe1's proposal seems to fit better than mine [09:39] fwereade_, have POST/PUT/GET support for charm urls prefix, like /charms/ and handle everything there [09:39] fwereade_, potentially caching the unpacked charms locally forever [09:39] dimitern, well we can't do that exactly [09:39] dimitern, HA [09:40] fwereade_: why is HA a problem there? [09:40] dimitern, we presumably want them, and everything else that doesn't have to be provider-level, in gridfs storage [09:40] fwereade_, do what? cache? [09:40] fwereade_: you could write it all into mongo [09:40] rogpeppe1: dimiter was saying 'localyl' [09:40] dimitern, which machine unpacked then? [09:40] as in /tmp, I believ [09:40] jam: i think that was with respect to caching [09:40] jam: which would be fine, i think [09:41] jam: although you'd want to keep a handle on the size of the cache [09:41] fwereade_, doesn't matter which machine [09:41] dimitern, well, we need the files on all the machines, right? [09:41] fwereade_, whichever api server serves a charm, it checks its local cache and populates it before serving [09:41] jam: and actually, it might not be worth caching - you don't need to unpack for a GET [09:41] fwereade_, no [09:42] rogpeppe1, you need specific files inside the package, like the icon.svg [09:42] rogpeppe1: so the request from fwereade_ was that you could serve just the icon.svg, for example, and that is not trivial to proxy without unpacking [09:42] ah, i hadn't realised that [09:42] * rogpeppe1 goes to look at the gridfs docs [09:44] jam: actually, i don't think it would be too hard [09:44] fwereade_, rogpeppe1, although I still think going with a pure http-based interface will screw us up badly when we need to think of role-based auth [09:44] dimitern: how's that? [09:44] dimitern: basic auth is username + password [09:44] i now that [09:44] I think oauth is an HTTP header [09:45] and you can always have X-Juju-Authorization-Token: XYZ [09:45] jam: +1 [09:45] but what don't know is would it be enough/like the api login [09:45] dimitern: it doesn't necessarily need to be [09:45] dimitern: did you see my reply to Gary's comment? [09:45] rogpeppe1, jam, dimitern: well, I want us to remain open to the possibility of alternative auth mechanisms [09:45] fwereade_: definitely [09:45] rogpeppe1, so using the same user/pass for login and for basic http auth [09:46] fwereade_: I think HTTP headers are just as turing complete as anything else [09:46] jam: actually, they're not quite [09:46] rogpeppe1, jam, dimitern: so issuing tokens from the API feels like it gets round that potentialcomplexity completely [09:46] ? [09:46] jam: you can't do a multi-stage login protocol [09:46] fwereade_, exactly [09:46] fwereade_, but then we don't solve the get issue [09:47] fwereade_: we could issue auth tokens from the API [09:47] fwereade_, and having to implement a get handler + a bunch of apis, rather than a bunch of http handlers only seems simpler [09:47] rogpeppe1: you could with round trips, and I'm pretty sure basic PUT can return an "please finish Auth" request. [09:47] fwereade_: which don't have any specific relationship to charms [09:47] jam: ah, ok [09:47] jam: sounds complex though. [09:48] jam, PUT can return 401 as POST or GET [09:49] rogpeppe1: that said, client sides may not implement the 100 Continue stuff, which would mean they try to upload the whole content and then get a "hey, you need to auth, please upload again" [09:49] fwereade_: in the future, i'm thinking of a method, say Client.AuthToken that returns an authentication token that can be used to authenticate future URL operations. [09:49] fwereade_: but for the time being, i don't think it's necessary. [09:52] rogpeppe1, actually it is i think [09:52] rogpeppe1, we can always generate a token and return it as a result of login [09:52] rogpeppe1, then we can use this token as a session key for url requests [09:52] rogpeppe1, and have a call to renew a token perhaps [09:52] dimitern: that's not a bad idea - i don't think it's *necessary* but it would work well [09:53] dimitern: for the time being we could just return the username and password [09:54] rogpeppe1, you mean ask for? [09:54] rogpeppe1, not return [09:54] dimitern: i mean that the auth token returned by Login would just embed the user name and password that was passed to Login [09:55] dimitern: the client would treat it as an opaque identifier [09:55] rogpeppe1, not in plain text though [09:55] dimitern: so if we changed to using a more sophisticated scheme in the future, the client would not need to change [09:55] dimitern: why not? [09:55] rogpeppe1, because it's a security leak [09:55] dimitern: how so? [09:56] rogpeppe1, returning the "usernamepassword" in plain text from the server? [09:56] dimitern: yeah [09:56] rogpeppe1, and then using that as a token? [09:56] dimitern: yup [09:56] rogpeppe1, why? [09:57] dimitern: how is it a security leak? [09:57] rogpeppe1, basic auth does that already - user/pass auth [09:57] dimitern: sure, and that's essentially what we're doing now [09:57] dimitern: how is it a security leak? [09:57] rogpeppe1, my point is that a token is probably either a part of the url (unsafe) or a header (with ssl probably safe) [09:58] dimitern: it would be part of the header (and the url is actually safe too with https, i believe) [09:58] rogpeppe1, unsafe, meaning if the token is not opaque, like you're suggesting [09:59] dimitern: we're talking about an authentication token, right? any time that leaks, it's a security leak regardless, whether it's plain text or not), [10:00] dimitern: i'm just suggesting we go with an ultra-simple approach to start with, which is sufficient for our current needs, and also capable for the future. [10:00] rogpeppe1, no it's not [10:00] dimitern: why not? [10:00] dimitern: rogpeppe1, fwereade_, TheMue, davecheney: weekly standup [10:00] rogpeppe1, an opaque token, which is time-sensitive is better, even if leaked the damage is minimized [10:00] mramm: standup if you're around [10:01] mgz: ^^ [10:01] https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.8sj9smn017584lljvp63djdnn8 [10:03] I'm there === gary_poster|away is now known as gary_poster [11:20] jam: bad news, -O2/s has no appreciable effect on binary size [11:20] well, -O2 made it 5% bigger [11:23] -rwxr-xr-x 1 dfc dfc 19M Dec 5 22:20 /home/dfc/bin/juju [11:23] -rwxr-xr-x 1 dfc dfc 22M Dec 5 22:20 /home/dfc/bin/jujud [11:23] ^ jam stripped [11:23] but I don't know if it is safe to do that with gccgo binaries [11:23] i'd guess it is probably safer than gc binaries [11:23] but i don't have enough experiecen [11:24] * dimitern lunch [11:24] * davecheney bed [11:41] davecheney: thanks for the reference point, sleep well [11:44] jam: antonio put me up to this, i swear [12:45] jam: urgh - I just got the --upload-tools thing when running from trusty with gccgo and trying the manage precise [12:46] esp if libgo is not statically linked.... [12:46] gah [13:34] jamespage: so as I understand from davecheney, it *is* intended that final binaries built with gccgo would be staticly linked to avoid 'what version is on what platform' problems [13:35] jam: not sure about the statically linked thing [13:35] that's something the security team where keen to avoud [13:35] libgo contains a core set of SSL libraries [13:35] so not having to rebuild for every security vulnerability is a + [14:18] rogpeppe1: *carefulPing* I changed the tailer now that it starts N lines before the end. only downside is that those N lines aren't already filtered, so that the initially returned lines can be less. [14:23] TheMue: presumably you could filter as you go back through the file? [14:25] rogpeppe1: should be possible too, only a bit more logic to create the right strings to check [14:25] rogpeppe1: and those may span two or more read buffers [14:28] rogpeppe1: but will try it after hangout (in 2 mins) [14:28] TheMue: yes, you may need to use something more like the code i sent you [14:30] rogpeppe1: a bit more of it, yes [14:30] rogpeppe1: btw, how about the storm in your hometown? here it's ok so far, but it still shall grow [14:31] TheMue: pretty windy today [14:32] rogpeppe1: yeah, we have some douglas firs in front of the house and they are swinging fine :) [14:33] rogpeppe1: so, off for some minutes, hangout [15:13] rogpeppe1, why is there a mutex in apiserver Login/ [15:13] dimitern: because it might be called concurrently [15:14] rogpeppe1, it seems I can reuse the same Login call for http basic auth [15:14] rogpeppe1, except for the loggedIn flag [15:14] dimitern: i'd abstract out a separate function called by both [15:14] dimitern: i did that in the example http handler code i posted a while ago [15:15] rogpeppe1, yeah, my thoughts exactly [15:19] dimitern: authUser in https://codereview.appspot.com/22100045/diff/20001/state/apiserver/admin.go [15:19] natefinch, I put you in an n+1 config yesterday. I built the windows installer juju 1.16.4 and verified I could bootstrap and deploy from windows with it. [15:20] sinzui: awesome [15:21] natefinch, I learned I can use wine+inno to make the installer. I don't have windows so I started an instance in aws. I learned about rdp and making ssh work. I think I know enough now to test this reguarly [15:21] sinzui: awesome. I hoped wine would work, but hadn't tried it myself. [15:25] sinzui: I think I will upgrade CI's system juju to 1.16.4. Any reason not to? [15:29] abentley, +1 to upgrade [16:20] TheMue: you have a review [16:21] rogpeppe1: thx [17:19] dstroppa: so, do you have lbox installed and working? [17:23] mgz: I'm getting an 'undefined: syscall.TCGETS' when I execute 'go get launchpad.net/lbox' [17:24] >_< [17:24] maaacs... [17:25] from goetveld/rietveld/terminal_darwin.go? [17:26] that should be worked around in latest release... [17:27] goetveld/rietveld/terminal.go [17:31] I have terminal_darwin.go and terminal_linux.go [17:36] here http://bazaar.launchpad.net/~goetveld/goetveld/trunk/files I can only see terminal.go [17:37] uuu [17:38] dstroppa: can you branch lp:~gophers/goetveld/trunk instead? [17:38] I'm not sure why we have two, at different revisions [17:39] dstroppa: or just try againt now, I've changed it on launchpad [17:40] so go get should now work [17:40] mgz: go get works [17:40] and now I got lbox [17:41] phew :) [17:41] okay, so now go to your gojoyent branch, and run: (adjust the path as needed) [17:41] `~/go/bin/lbox propose --for lp:~juju/gojoyent/for_review -cr -v -wip` [17:42] which does some stuff, then should bring up an editor for you to write a review message in [17:42] also creds for g+ and launchpad as part of it... painful but hopefully not too bad [17:44] Branch is not clean (I got some file that are not pushed yet as I'm still working on it) [17:44] shall I move them or can work around it? [17:44] shelve those bits then run it again [17:45] `bzr shelve --all -m "wip whatever"` [17:45] and `bzr unshelve` when you want it back [17:48] sh: sensible-editor: command not found [17:48] heh [17:49] set EDITOR to something? [17:49] this is the flakiest tool... [17:53] error: Change summary is empty. [17:53] even though I added both summary and desc [17:55] dstroppa: the code opens a tempfile, execs your editor with that name, waits for it to exit, seeks to 0, then reads [17:55] is there anything there that would get upset for you? [17:57] or maybe just a blank line at the top or something daft? [17:57] I believe no [17:57] it opens up vi [17:57] I edit the file (replace the with my text) [17:57] save and close [17:58] feel free to poke at lbox text.go to work out why it's being fussy [17:58] vim's what I use so I'd expect it to be fine for you as well [18:05] dstroppa: any luck? [18:06] tried vi and vim, same error [18:07] looking at text.go, but can see anything in particular [18:09] could just add a log statement to dump the file name/contents before that error, see if that makes anything clearer [18:26] mgz: looks like it's still reading the template [18:26] even though the temp file is saved [19:02] so is safe mode the default? [19:05] on juju 1.16.4-precise has anyone else been experiencing 'unauthorized mongo access' errors? [19:15] hatch: from where, to where? from the 'juju' CLI or from agents, or ? (It hasn't been reported before, but it is worth investigating) [19:16] jam so I just did a apt-get upgrade and now when I type `sudo juju bootstrap` I get that error [19:17] hatch: so this is for local provider ? [19:17] correct [19:17] (otherwise you wouldn't be using sudo, presumably) [19:17] hatch: can you try "sudo juju bootstrap --debug" and then paste bin the result (it might have secrets if you want to be careful) [19:18] sure one sec [19:20] hatch: also, what version of 'mongodb' is on your machine? (dpkg -l mongodb-server) [19:20] jam I think here are the relevant bits https://gist.github.com/hatched/3e8a13af98250c236c9d [19:20] 1:2.2.4-0ubuntu1~ub [19:21] hatch: what series are you on? (precise/raring/etc) [19:21] precise [19:21] these issues appeared after the update to ,4 [19:21] so I'm not saying to do this *yet* but we do have mongodb-2.4.6 in the cloud-archive: sudo add-apt-repository cloud-archive:tools [19:22] hatch: the actual changes of 1.16.3 vs 1.16.4 don't seem like they would be causing db auth problems, but I'll dig a bit [19:22] I saw some emails going by that talked about a juju specific mongodb [19:22] did those land in .4? [19:22] hatch: I just "juju destroy-environment; and then juju bootstrap" locally and it worked on precise, so it *might* be the newer mongodb [19:22] hatch: no [19:23] that is going to be a while in the future [19:24] ahh ok ok [19:25] hatch: so I know we didn't intend to change anything about how we connect to the db in 1.16.4 vs 1.16.3, and I confirmed the diff doesn't appear to contain a change there. [19:26] very odd... [19:26] hatch: are you bootstrapping with a DB already configured or something like that ? (I wouldn't think you would get this far) [19:26] jam I'm going to say no.... [19:28] I've tried deleting the local/ and environments/ but that doesn't appear to help [19:30] hatch: well if you delete those, then you can't "juju destroy-environment" properly, which means you possibly *do* have a stale DB that we aren't aware of (maybe) [19:30] oh hmm [19:30] any idea on how I would wipe it clean? [19:30] hatch: just to try it "juju destroy-environment -e local; sudo juju bootstrap -e local" [19:30] or whatever you named it [19:30] same [19:31] issue [19:35] hatch: I'll try to install 2.2.4 here, but so far I have no luck reproducing your issue (next step is to install the 1.16.4 binary that was built, because it might be flawed somehow vs building from trunk) [19:36] jam is there a way I could clear out my mongodb besides the destroy-environment call? [19:36] hatch: btw, do you know about paste.canonical.com? it requires Auth tokens so is generally 'safe enough' when pasting private stuff. [19:37] hatch: well, "create mongo journal dir: /home/jameinel/.juju/local/db/journal" so I'm 95% sure that deleting ~/.juju/local would have done that [19:37] ahh ok that was my thought process as well [19:39] jam yeah I usually dont' use that paste because it doesn't allow edits [19:39] hatch: can you paste your local config ? [19:39] sure [19:40] https://gist.github.com/hatched/72ce29821d4c56c76280 [19:40] nothing changed in there since the update [19:40] hatch: sure, you could *try* just commenting out the admin-secret [19:40] as we should generate one for you if it isn't present [19:40] but I haven't been able to reproduce the problem [19:40] ok trying [19:41] nope :/ [19:41] darn [19:41] hatch: I didn't expect much there, as there is no reason to expect the value there is invalid. I also can't reproduce on Precise with the jujud binary installed from the ppa and mongo from that ppa as well. [19:42] hatch: maybe you can pastebin more of the log? In case there was a config earlier that is wierd [19:42] weird [19:43] natefinch: I'm about to head to bed, any chance you can give this a look ? I'm skeptical that this is caused by 1.16.4 vs 1.16.3, but I'd really like to know what a root cause is [19:43] thanks for the help jam - maybe what I'll do is remove juju and mongo and start frash [19:44] fresh* [19:44] maybe something got messed up in the update [19:44] or maybe wallyworld or thumper depending on who logs in first (we're almost around to start-of-day NZ I believe) [19:44] hatch: I would like to understand what is broken, but I can also understand you just want to get it working [19:45] well the good news is that I don't need to test any new GUI work until tomorrow :) [19:45] haha so I have until then [19:45] its nearly 8am in NZ, so thumper should be around soon. and rogpeppe2 is often known as a very helpful fella :) [19:46] though its past his EOD, I believe [19:46] jam: it is :-) [19:46] jam: I'm here [19:46] jam: took a jaunt to the Lexington, MA office, since they wanted to see Ubuntu on my laptop (high DPI screen) [19:47] natefinch: k, brief summary, hatch upgraded to 1.16.4 from the ppa, and now when he tries to bootstrap it gives him unauthorized failures [19:47] I'm unable to reproduce, even using Precise + mongo-2.2.4 + juju-1.16.4 from the PPA [19:47] natefinch: sounds fun [19:47] how far away is it for you? [19:48] natefinch this is the error https://gist.github.com/hatched/3e8a13af98250c236c9d [19:48] 1/2 hour, not bad at all. Had lunch with David Pitkin, old colleague from our younger startup days [19:49] hatch: hmm.. interesting [19:49] I've tried deleting the environments/ and local/ as well as doing a destroy-environment and no luck [19:50]