=== jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === jfarschman is now known as MilesDenver === kickinz1|afk is now known as kickinz1 === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver [12:38] blake_r: I know this is very much in flux still but Jeroen and I filed a couple of bugs related to the work you're doing on the new import image stuff: https://bugs.launchpad.net/maas/+bugs?field.tag=boot-images === jfarschman is now known as MilesDenver === jfarschman is now known as MilesDenver [13:18] rvba: thanks === jfarschman is now known as MilesDenver [14:24] juju status [14:24] WARNING discarding API open error: read tcp 127.0.0.1:37017: i/o timeout [14:24] ERROR Unable to connect to environment "maas". [14:24] any hints as to why the machine is mad? [15:48] Hey, I was wondering, is there an way to tell MAAS to NOT disable the ubuntu user password? Is it MAAS or is it cloud-init/curtin that disables the user PW for Ubuntu? [15:50] bladernr_: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L554 [15:50] Define "disable" though. [15:52] Since cloud images ship with no ubuntu user password set, what do you mean by MAAS disabling it? [15:52] It ships that way. [15:58] I have custom spun fast-path images that are built from a d-i preseed that include an ubuntu user and default password. However, once the image is installed via MAAS (no juju here), using fast-path, when I ssh in and check /etc/shadow, the password for Ubuntu has been prepended with a '!' which disables it. [15:59] ^^ I'll add that I'm blaming MAAS for now, I haven't had a chance to actually break into the FP image I created to verify for certain that it's not being munged during installation. But I'm 80% sure it's not the image itself. [16:00] FWIW, the custom-spun bit is just "Boot a VM from an ubuntu ISO, d-i w/ pressed to install what I need, then tar the filesystem up so I can later pass it to MAAS" [16:01] So you're trying to introduce a vulnerability in your deployments, and something's stopping you? :) [16:01] It might be cloud-init. Or curtin. Nothing else will mess with the system that I'm aware of. [16:01] (unless instructed via cloud-init or curtin) [16:01] It's not necessarily a vulnerability, it's for cert testing so the systems are only installed long enough to run tests [16:01] Oh, I see. [16:01] unfortunately, I need to be able to pass a sudo password to checkbox to authenticate when it needs root access on its own [16:02] Then just using cloud-init is getting in your way here. But MAAS sort of assumes that. [16:02] checkbox runs root tests in a subshell on the system, so ssh key auth doesn't work. [16:03] mkay... I'll do more digging on cloud-init then. I looked at curtin and couldn't find anything yesterday that would do it. so that gives me a place to start. Thanks! [16:03] smoser might know [16:03] ^^ or a much better place to start at least. [16:03] I wonder if there's a better way to do this though. [16:03] Maybe supply a password at the time you request the machine, and let cloud-init set it up as designed instead of fighting it? [16:04] (via userdata - see my link above) [16:04] maybe... another thing I didn't try was setting it directly in userdata. That was going to be my next experiment, but I ran out o ftime and won't be able to get back to it until next week [16:05] I would try that first, since that's the "regular" expected way of achieving this. [16:05] so one thing not clear in that link... it says By default in the UEC images password authentication is disabled [16:05] # Thus, simply setting 'password' as above will only allow you to login [16:05] # via the console. [16:06] so does that imply that setting the password there will disable the use of ssh keys for ssh logins? so you would also need to set the ssh stuff in the next few lines? [16:06] I think what it's saying is that _ssh_ password auth is disabled by default. [16:06] ahhh ok [16:07] So in addition to setting the password you need to explicitly enable ssh password auth. [16:07] In your images you may not need that. [16:07] bladernr_, its cloud-init that *creates* the ubuntu user. [16:08] * rbasak did not know that [16:08] smoser: ok... so my images already have an ubuntu user, with a default password for certification. so looks like in that case, cloud-init just preserves the user but disables the existing password [16:09] bladernr_, you can probably disable it. but i wonder why you care that it lets password auth in. [16:09] when in a working path, you'd have non-password auth, which is magically better. [16:10] smoser: because of checkbox. I'm happy with ssh key auth for logging in via ssh, but when I run checkbox on test machines, it needs an active local password for root escalation because it runs some jobs in a subshell [16:10] well, in that same working path, cloud-init would have set up passwordless sudo for the user :) [16:11] what i might suggest is that you just tell cloud-init that its default user is something other than ubuntu. [16:11] and then it will create and manage that user and not touch yours. [16:11] (alternatively, you could rename yours) [16:11] right, but even that didn't work. (it DID set up passwordless sudo) but, and I think it's policykit doing this, roadmr and zyga would know more, when checkbox runs, it still requires the password to work... :/ [16:12] bladernr_, well, so 2 options then. [16:12] and you're right, actually just changing the default we use from ubuntu to certification or something would be far simpler a workaround [16:12] a.) you don't create 'ubuntu', you use "fubuntu" [16:12] bladernr_: if the user running checkbox has authorization for passwordless sudo, that should suffice for checkbox purposes [16:12] roadmr: it didn't yesterday :( [16:13] checkbox still prompted me and failed the auth... [16:13] b.) in user data or /etc/cloud/cloud.cfg you change 'name: ubuntu' to 'name: fubuntu' [16:13] bladernr_: could you show me a screen cap of the prompt it used? [16:13] roadmr: not really, ive already torn the node down and packed up my maas server (and I'm in the air anyway, so not able to fire it up) [16:13] i guess also [16:14] roadmr: changing the user from 'ubuntu' to certification would be a much better solution anyway. [16:14] c.) you change /etc/cloud/cloud.cfg to have 'lock_passwd: False' [16:14] roadmr: simple and non-invasive. [16:14] smoser: rbasak thanks... I'll keep that in mind when I get back to playing with these custom images. and thanks for helping me understand better how this all works together. [16:15] bladernr_: that can be done in the curtinator preseed (I'm assuming that's what you used to generate the image). Look at passwd/username; or you could add an additional user in the late_command === bladernr_ is now known as bladernr_30kFeet [16:16] roadmr: yeah, I know and that's what I'll do. (plus play around a bit more with coud-config to better learn how it works. [16:16] bladernr_30kFeet: ok... do let me know when you're on the ground, we can definitely figure this one out === roadmr is now known as roadmr_afk [19:13] allenap: Do you have any advice for testing stuff done with callLater()? At the moment I’m just mocking the reactor, but that seems like not a very good test. [19:13] s/seems like/is/ [19:24] gmb: twisted.internet.task.Clock [19:25] gmb: You might have used it before. It implements IReactorTime, which is a subset of what a whole reactor provides, but it’s probably enough. [19:26] allenap: Sorry, I’m not quite getting what you’re suggesting I do with Clock there. [19:26] gmb: Create an instance of Clock and pass it into whatever you’re calling, pretending that the clock is the reactor. [19:27] allenap: OIC. With you now. Thanks. [19:30] gmb: There are some examples around the codebase. You get to choose when the delayed calls are called. Otoh, you could also use reactor.getDelayedCalls() to see what’s pending (and cancel if you want), or use reactor.runUntilCurrent() to actually call things (assumes that the call you’re interested in is the only delayed call). [19:31] allenap: Okay, thanks. [19:32] allenap: Whichever of those approaches I choose, I end up with an UncleanReactorError [19:33] (So I’m probably doing something rong) [19:33] hang on, lemme paste the test case… === CyberJacob|Away is now known as CyberJacob [19:33] s/TestCase/diff/ [19:34] allenap: http://paste.ubuntu.com/8420350/ line 212ish [19:40] gmb: Okay, I can recreate it, I’ll see what I can figure out. [19:41] allenap: Much obliged squire. I’ll check back in a bit later. [19:54] gmb: Try using: callLater(0, …) [19:54] i.e. zero delay. [19:55] gmb: Actually, there’s something else going on… === roadmr_afk is now known as roadmr [20:21] gmb: Here’s what I’ve come up with: http://paste.ubuntu.com/8420574/ [20:28] allenap: Grand! Thanks.