[09:22] <rvba> allenap: I'm trying to test some things but bug https://bugs.launchpad.net/maas/+bug/1365742 is getting in the way.
[09:23] <rvba> I'm seeing http://paste.ubuntu.com/8325785/ over and over.
[09:23] <rvba> What does the "No exception type: No exception value" error mean?
[09:23] <allenap> rvba: Okay, I’ll look at that now.
[09:24] <rvba> allenap: Ta, I'm happy to help (I really need this solved).  Let's work together on this.
[10:07] <rvba> allenap: any idea what might be wrong?
[10:08] <gmb> allenap: When you’re done helping rvba, do you have time to chat about serialising power commands? (This is the thing that Kiko reckons needs Face Time. I’m not so sure…)
[10:10] <allenap> rvba: Nope, not yet. I’m going to try and reproduce it on my NUCs. Or can I reproduce it in a dev environment?
[10:11] <allenap> gmb: Yes indeedee.
[10:11] <rvba> allenap: I think you need real systems.
[10:11] <allenap> Here’s one I prepared earlier...
[10:13] <rvba> allenap: I put debugging statements everywhere in send_event_node (src/provisioningserver/events.py) and I can see that everything looks normal: no need to register the event type (because it already exists) and I still see the exception in pserv's log!
[10:20] <gmb> allenap: Cool. Ping when free, then.
[10:55] <rvba> allenap: https://bugs.launchpad.net/bugs/1368685 … weird, never seen this…
[11:15]  * gmb -> lunch
[11:24] <allenap> rvba: I can’t reproduce https://bugs.launchpad.net/maas/+bug/1365742 now.
[11:24] <allenap> rvba: What do you do?
[11:24] <rvba> allenap: I just uninstall amtterm and commission nodes.
[11:43] <allenap> rvba: I think I see what it might be. Try applying http://paste.ubuntu.com/8326460/ to a branch and running bin/test.pserv.
[11:43] <allenap> rvba: The power commands mix synchronous and asynchronous code and get it slightly wrong.
[11:44]  * rvba reads the docstring of the 'synchronous' decorator.
[11:48] <rvba> allenap: the decorators are just belt and braces right?  The real changes are 'yield' and 'wait' correct?
[11:48] <allenap> rvba: They are, yes, though the asynchronous decorator does automatically use crochet when calling an async function from outside of the reactor.
[11:49] <rvba> allenap: all of this code runs in pserv… why is crochet involved at all?
[11:55] <allenap> rvba: It shouldn’t be in pserv; that’s really for the benefit of the region. That’s what alerted me to this problem, because I saw mention of EventualResult in pserv.log.
[11:57] <rvba> allenap: why shouldn't it be in pserv?  The cluster is in charge of all the power-related operations.  Then it reports back to the region via RPC.
[11:57] <allenap> rvba: Fwiw, the crochet functions run_in_reactor and wait_for_reactor are okay to use in pserv, though they’re not needed much. We just don’t want to use crochet to start up the reactor there.
[11:57] <allenap> rvba: I mean crochet shouldn’t be used (much) in pserv.
[11:57] <rvba> My understanding was that crochet was only there as a bridge between Django and twisted.
[11:58] <allenap> rvba: It’s a bridge between any threaded code and the reactor.
[11:59] <allenap> rvba: So if, say, a power action in pserv needs to use RPC, it’s find to use crochet.run_in_reactor, say.
[11:59] <allenap> s/find/fine/
[12:00] <rvba> allenap: so: reactor → threaded code using deferToThread and to talk *back* you can use crochet?
[12:02] <rvba> allenap: back to the point, why did you say this shouldn't be in pserv?  I really don't understand.
[12:14] <allenap> rvba: I saw “Unhandled error in EventualResult” in pserv.log. EventualResult is part of crochet. But send_event_node must clearly be run in the reactor… if it’s run outside of the reactor the `yield client(…)` bits would be returning EventualResult objects, which inlineCallbacks doesn’t recognise and wouldn’t wait for; it would then proceed
[12:14] <allenap> straight onto the next `yield client(…)`. At that point there’s a race.
[12:15] <rvba> allenap: okay, I misunderstood what you said.  To me, "not in pserv" means "not in the cluster", i.e. in the region.
[12:15] <allenap> rvba: In other words, both of those client(…) calls in send_event_node would be called in very quick succession, and nothing would be waiting for the first (or the second) call to complete.
[12:16] <rvba> allenap: yeah, I get it now.
[12:16] <allenap> rvba: Cool. I don’t mind fixing it, unless you’re desperate to do it?
[12:17] <allenap> gmb: I’m going to have a quick lunch. Want to talk right after that?
[12:17] <rvba> allenap: You already have a diff, I'll test it… maybe you can put the branch together in the meantime.
[12:18] <allenap> rvba: Okay. I hope the diff fixes it :)
[12:18]  * allenap goes for lunch
[12:47] <gmb> allenap: I’m free from now until ~14:15, then I’m getting on a train, so whatever works for you :)
[12:51] <rvba> allenap: looks like your diff fixes the problem.
[13:30] <allenap> rvba: \o/
[13:31] <allenap> rvba: Want to review it? :) https://code.launchpad.net/~allenap/maas/rpc-power-sync-async-mix-up/+merge/234465
[13:33] <rvba> allenap: nice; why don't we need run_tests_with = MAASTwistedRunTest again?
[13:47] <allenap> rvba: The ones that use the IOPump don’t touch the reactor. Some of them used that so they could return a Deferred and let the test runner figure out if there was a failure, but the Deferred had all fired so I used extract_result() to check them.
[13:49] <allenap> blake_r: Are you going to resurrect your work on the report_boot_images task?
[13:58] <roaksoax> allenap: he is away to day unfortunately
[14:02] <allenap> roaksoax: Okay, I’ll see if I can find his work and finish it off.
[14:04] <roaksoax> allenap: thanks! I see he has just one branch left!
[14:07] <roaksoax> allenap: although, I'd say you should finish the update_node_tags card first though
[14:07] <allenap> roaksoax: Agreed, that’s what I’m working on now.
[14:07] <roaksoax> allenap: perfect! tha nks
[14:14] <rvba> allenap: doing another round of testing now that your code has landed.
[14:34] <roadmr> roaksoax: ok, it's for that provisioning project we discussed a while back. I have an ubuntu desktop image that can be installed with curtin, now I'd like to be able to select it for maas to install it on a node
[14:36] <roadmr> roaksoax: I poked a bit at things and I'm not sure if I have to just drop the image somewhere in the maas server, or if I have to provide a more complex structure (simplestreams, a keyring, that stuff)
[14:37] <roaksoax> roadmr: you can just drop a curtin image in MAAS, and MAAS would install it
[14:37] <roaksoax> roadmr: the image would be a cloud image like, which smoser could provide more input on
[14:39] <roadmr> roaksoax: oh so the image needs some metadata or extra stuff?
[14:54] <roaksoax> roadmr: not really. The only thing that the image would need is just basically be like a cloud image
[14:55] <roaksoax> roadmr: smoser would have a better idea of what it needs in regards to curtin/cloud-init
[14:55] <roaksoax> roadmr: the thing is that once installed, cloud-init contacts the MAAS server to run final tasks
[14:55] <roadmr> roaksoax: oh I see... I already tested installing my image with curtin so that part is done, I'd need to look into cloud-init
[14:56] <roadmr> roaksoax: once the image is ready, where should I put it? I'm looking in /var/lib/maas/boot-resources, there's a lot of structure there so I'm wondering where it should go
[14:56] <roaksoax> roadmr: I think you'd just need to have cloud-init in your image
[14:56] <roaksoax> roadmr: if you are using MAAS 1.7, you would just be able to upload the image to MAAS via the CLI
[14:57] <roadmr> roaksoax: oh! well I'm not, but that can be easily remedied. /me upgrades
[14:57] <roadmr> roaksoax: (we get to dictate requirements, yay, so if MAAS 1.7 makes things significantly easier, we can just require that)
[15:01] <roaksoax> roadmr it does. you'd just need to upload an image and that's it. I'd recommend you talk to smoser for this
[15:03] <roadmr> roaksoax: I will! thanks! now let's see about upgrading this thing
[17:53] <fgiraldeau> Hello! I installed MAAS, and then defined a faster deb mirror. The setting in /etc/apt/sources.list is correct, but I was getting 403 Forbidden on the Package file while doing "apt-get update"
[17:54] <fgiraldeau> I had to change the setting in squid-deb-proxy, adding the new mirror in the file /etc/squid-deb-proxy/mirror-dstdomain.acl.d/10-default
[17:54] <fgiraldeau> and then service squid-deb-proxy restart to solve the issue
[17:55] <fgiraldeau> I think that changing the MAAS mirror setting in the web interface should add the mirror to the squid repo, otherwise it won't work
[17:55] <fgiraldeau> Shall I open a bug for that?
[19:25] <roadmr> roaksoax: ok, I got maas 1.7 up and running, how do I upload my image? I got maas (cli) setup and logged in. If there's a doc describing this, I'm happy to dive in and read it
[20:55] <kiko> hey there
[20:55] <kiko> I've got a maas install from experimental on trusty
[20:55] <kiko> and I can't get boot images to load
[20:55] <kiko> does anyone know a workaround for that?
[20:56]  * kiko looks at blake_r and roaksoax
[21:03] <fgiraldeau> OK, well after checking, the bug about squid-deb-proxy is already reported: https://bugs.launchpad.net/maas/+bug/1300266
[21:30] <roaksoax> kiko: when you click on the webui it does not download the images?
[21:30] <roaksoax> kiko: try: maas admin boot-resources import
[21:30] <kiko> will do
[21:30] <roaksoax> kiko: and check progress wiht: maas admin boot-resource read 1 | grep progress
[21:31] <kiko> oh nice
[21:31] <roaksoax> kiko: all the functionality is there, we just have to make it available in the WebUI
[21:32] <roaksoax> kiko: so that will donwload the images to the DB
[21:32] <roaksoax> kiko: and then it will tell the clusters to import the images


 QUESTION: If you encript all you home directory (as the original idea) you still need password (login) and mount passphrase?
[21:48] <kirkland> yes.  auto-login will almost certainly *not* work
[21:49] <kirkland> with respect to the 2 passphrase (login, and mount) ...
[21:49] <kirkland> i'll remind you that in normal Encrypted Private operation, *all* you really need is your login passphrase
[21:49] <kirkland> your mount passphrase is decrypted and used on the fly, under the covers
[21:50] <kirkland> they *only* time you should ever need to manually use your mount passphrase is when/if you have to manually recover your data elsewhere, later
[21:50] <kirkland> let's say you've kept good backups of your encrypted data in .Private offsite
[21:50] <kirkland> and you're at a friend's house, or a client site, or something
[21:50] <kirkland> and you need access to one of your files, let's say .Private/foobar
[21:51] <kirkland> assuming you have access to a Linux machine with at least a 2.6.19 kernel with ecryptfs support (ideally, more like 2.6.27 or later)
[21:51] <kirkland> you could:
[21:51] <kirkland> mkdir /tmp/1 /tmp/2
[21:51] <kirkland> cp .Private/foobar /tmp/1
[21:52] <kirkland> sudo mount -t ecryptfs /tmp/1 /tmp/2
[21:52] <kirkland> and then you'll get a series of interactive questions:
[21:52] <kirkland> Select key type to use for newly created files:
[21:52] <kirkland>  1) pkcs11-helper
[21:52] <kirkland>  2) openssl
[21:52] <kirkland>  3) passphrase
[21:52] <kirkland>  4) tspi
[21:52] <kirkland> Selection:
[21:52] <kirkland> (these answers will be for the default Intrepid Encrypted Private setup)
[21:52] <kirkland> ->  3) passphrase
[21:52] <kirkland> Passphrase:
[21:53] <kirkland> -> your_mount_passphrase_that_you_wrote_down_and_stored_somewhere_safe
[21:53] <kirkland> Select cipher:
[21:53] <kirkland>  1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
[21:53] <kirkland>  2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
[21:53] <kirkland>  3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
[21:53] <kirkland>  4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
[21:53] <kirkland>  5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
[21:53] <kirkland>  6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
[21:53] <kirkland> Selection [aes]:
[21:53] <kirkland> -> aes
[21:53] <kirkland> (note that these are the other ciphers that ecryptfs supports)
[21:54] <kirkland> Select key bytes:
[21:54] <kirkland>  1) 16
[21:54] <kirkland>  2) 32
[21:54] <kirkland>  3) 24
[21:54] <kirkland> Selection [16]:
[21:54] <kirkland> -> 16
[21:54] <kirkland> (we might consider moving this up in Jaunty)
[21:54] <kirkland> Enable plaintext passthrough (y/n) [n]:
[21:54] <kirkland> -> n
[21:54] <kirkland> (I'll explain this if someone really wants to know)
[21:54] <kirkland> Attempting to mount with the following options:
[21:54] <kirkland>   ecryptfs_key_bytes=16
[21:54] <kirkland>   ecryptfs_cipher=aes
[21:54] <kirkland>   ecryptfs_sig=c7fed37c0a341e19
[21:54] <kirkland> Mounted eCryptfs
[21:55] <kirkland> then, you can look at /tmp/2/foobar and your data is available in the clear
[21:55] <kirkland> sudo umount /tmp/2
[21:55] <kirkland> and it's protected again
[21:55] <kirkland> note that you could have done this with the entire directory hierarchy
[21:56] <kirkland> that's pretty much all i have on my mind at the moment :-)
[21:56] <kirkland> any other questions?
[21:56] <kirkland> maybe time for 1 more?
[21:57] <kirkland> well you've been a great audience :-)  thanks for your time and attention!
 QUESTION: where do I find more info?
[21:58] <kirkland> let's see ...
[21:58] <kirkland> the design docs for Intrepid's Encrypted Private are: https://wiki.ubuntu.com/EncryptedPrivateDirectory
[21:59] <kirkland> the quickstart help guide is: http://help.ubuntu.com/community/EncryptedPrivateDirectory
[21:59] <kirkland> the upstream project page is https://launchpad.net/ecryptfs
[21:59] <kirkland> ubuntu bugs in ecryptfs is: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils
[21:59] <kirkland> the user's mailing list is<EMAIL_ADDRESS>[22:00] <kirkland> join the launchpad team: https://edge.launchpad.net/~ecryptfs-users
[22:00] <kirkland> and get a little badge :-)
[22:01] <kirkland> if you're interested in development: https://edge.launchpad.net/~ecryptfs-devel
[22:01] <kirkland> okay, i think that's all from me
[22:02] <quintale> thanks a lot
[22:02] <kirkland> and i just checked my email ... encrypted filename patches just hit LKML in the last hour :-)
[22:03] <komputes> kirkland: and implemented into intrepid by when?
[22:03] <kirkland> komputes: this one will not be implemented in intrepid
[22:03] <komputes> jaunty it is... :(
[22:03] <kirkland> komputes: think jaunty
[22:04] <kirkland> it's a major change that involves a large kernel patch, and userspace changes
[22:04] <kirkland> anyway, i think i'm done!
[22:04] <komputes> thanks for the presentation man
[22:04] <tonytiger> thanks kirkland
[22:04] <gv0rr> thanks
[22:04] <kirkland> come visit in #ubuntu-hardened sometime ;-)
[22:04] <Rafik> kirkland: thank you
[23:56] <danbhfive> test
[23:56] <jmk2> danbhfive: ?
[23:57] <danbhfive> mk, its just quieter here
[23:57] <danbhfive> do you have a terminal open?
[23:57] <jmk2> yep
[23:57] <woody86> is UTC the same as GMT?
[23:58] <danbhfive> jmk2: sudo apt-get dist-upgrade
[23:59] <stdin> woody86: yes
[23:59] <jmk2> i get the following:
[23:59] <jmk2> E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
[23:59] <jmk2> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
[23:59] <woody86> stdin, thanks :D just checking
[23:59] <stdin> danbhfive, jmk2: please don't use here as a support channel. use /msg
[23:59] <woody86> stdin, I seem to keep on missing the classes, and I don't like it :(
[23:59] <danbhfive> mk
[23:59] <stdin> woody86: logs are already up


[02:19] <Dzeg_-> hi out there! i got a question how can i check a imputDialog was filled; if this is not filled show the imputDialog again; sorry for my bad english