[01:53] It looks like the DataSourceEC2 manages block device mappings and it's the only datasource that does so. Is your custom datasource "done" when you have it being detected and setting up networking basically? [15:58] hrm. if i specify simply password=foo in the seed file does that apply to the root account by default, or some other account? [15:59] i thought the acc name on debian clouds was 'debian' but debian/foo isn't working [16:11] johnjaye: which "seed file"? password=foo is not valid in the user-data YAML file is that is what you are referring to [17:20] well ok. but that's what the man page for cloud-localds said to write [17:20] so i assumed it was a meaningful example [17:23] johnjaye: you mean the Examples section of that manpage? it mentions "password: ", not "password=" [17:23] as the first form *is* valid YAML [17:24] i have it as password: blah [17:25] johnjaye: ok, in your earlier post you said "password=foo" so that what what I commented on [17:25] so unless yaml has some sneaky way of tricking you with non-printable characters i got no idea [17:25] s/what what/was what. [17:26] i guess the first line has to be like #cloud-config or something [17:26] the manual said that i thought [17:28] best to look at the cloud-init docs for examples [17:33] johnjaye: when you say "debian/foo" isn't working do you for logging onto the VM's console? or via SSH? typically in "cloud" images SSH access is only enable via SSH key and not via password [17:35] the vm console [17:35] oh i see. so i need to forward ssh to this qemu instance then [17:35] johnjaye: ? you just said you are using the console so then SSH is not relevant [17:36] yeah. you made it sound like direct login wouldn't work [17:36] so i may need to add something for that [17:37] so assuming that the VM image you are using has defined "debian" as the default user for cloud-init (you would have to either check the image yourself or ask whomever created the image to determine this) and that you created a seed ISO with user-data containing "#cloud-config\npassword: foo\n" then yes you should be able to login as debian/foo [17:42] where the "\n" above represent actual line breaks [17:44] hmm that didn't work either. i'll read the manual and play 20 questions with the syntax later [17:46] johnjaye: which exact debian image are you using? [17:47] ones from the wiki, under 'cloud'. they provide several. named like debian-12-generic-i386.{raw,qcow2,vmdk} [17:47] johnjaye: which *exact* one? [17:47] idk what you mean. the copy i have is debian-11-generic-arm64.qcow2 [17:48] is it customary to provide daily cloud image snapshots? i thought there were dozens of them by date [17:51] johnjaye: that's that Debian decision [17:52] s/that /a / [18:06] johnjayne: right, add the following line to your user-data file: "lock_passwd: false", rebuild the seed ISO and try again [18:06] by the way, can cloud-init do stuff like setup sudo or user groups and such things? [18:06] that Debian image does use "debian" as the default username but it also locked that user for password access [18:06] johnjaye: yes, see https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups [18:10] is False interchangeable with false [18:10] either way i capitalized it [18:10] I believe YAML treats "false" and "False" as the same [18:10] actually...I don't think so. In yaml I think it's only false [18:11] falcojr: ok. i was wondering if it would be that unusual to try using cloud-init to change settings on a regular system. [18:11] falcojr: "yamllint" could be used to be sure... [18:12] minimal: when you say you're a cloud dev, does that mean you work on cloud-init itself or that you use it [18:13] both [18:13] oh. i see [18:13] this whole cloud world seems like it has its own culture and idioms [18:13] like provisioning. the disk being called /dev/vda [18:13] or ssh being the 'obvious' default [18:14] johnjaye: /dev/vda is a virtio-blk devices, that's nothing specific to cloud-init [18:14] whereas /dev/sda could be a SCSI device, or a virtio-scsi device, or a SATA device [18:14] that's a Linux thing, not a cloud-init thing [18:14] ah my bad. ok it says the root account is locked [18:15] maybe i should have said false not False... [18:15] johnjaye: root? you're supposed to be testing the "debian" account [18:15] right. i mean, that's what the startup message says [18:15] Cannot open access to console, the root account is locked. [18:16] have you tried to login as debian/foo ? [18:16] hrm. i think it's just taking a lot longer. i'm on my pi now and it has an sdcard [18:16] so qemu takes like 4x as long to boot up. [18:17] maybe if i plug in a usb stick it would be faster [18:17] lol. what is a randomart image for an ssh key. [18:17] it shows several [18:19] ok debian/foo did work and i logged in [18:19] johnjaye: have you not seen this output when you booted this VM image previously? It should appear the 1st time you boot a cloud-init based VM [18:19] \o [18:19] minimal: it all goes by so fast you can't read it [18:19] look at /var/log/cloud-init-output.log [18:20] now i do believe you're a cloud dev. i would never have randomly guessed that filename [18:21] that only shows the ssh art and something about ipv6 [18:22] cloud-init.log doesn't either afaik. so maybe those were dmesg [18:23] ah at least sudo is configured. that's nice [18:23] which output were you looking for? I thought you wanted to see the ssh art again [18:24] heh. no that message about root account being locked. i don't see it in those logs you said [18:24] or in dmesg [18:25] but hey at least it lets me login. that's amazing [18:25] so for that debian VM image the root account is locked, it is configured so that cloud-init will create a "debian" user by default but lock the account's password, so you need to set user-data appropriate for what you want. [18:26] is that common in cloud stuff [18:26] johnjaye: that would be likely in "journalctl" output as usual, nothing to do with cloud-init [18:26] like when i said password: foo how did that automatically apply to 'debian' and not say 'root'. or 'admin'. or something else [18:27] johnjaye: it's up to whoever packaged the disk image to decide, typically for images on cloud providers password access via SSH is disabled and SSH public keys have to be provided in user-data (along with any users/groups you want to add) [18:27] yeah but i meant the yaml file [18:28] how does it decide what to apply password: foo to. just the first user account? [18:28] johnjaye: "password: " applies to the default user defined in /etc/cloud/cloud.cfg ("default_user:", "name:") set by the Debian people [18:28] what if there isn't one [18:28] the same way that they alos have "lock_passwd: True" in there [18:28] then there's just no login as root or anything else [18:29] johnjaye: there's always a default user, that's why it is called the default user... [18:29] i thought you can create unix systems with no users. just root [18:29] like in the past when i install debian sometimes it does that [18:30] no users, i have to manually create them [18:31] well my previous statement is not 100%, when you create additional users in user-data you can decide whether or not the default user is also created [18:31] oh ok [18:32] and when you're doing this sort of thing is it for a person usually [18:32] but the idea is "out of the box" if you don't specify users then you get the default user [18:32] as in like an individual customer. or is it more like you need to automate setting up 1000 debian instances for a CI thing [18:33] it is whatever you want to do - for each Vm you create you provide user-data (and other settings) for that VM [18:33] ok. i was reading about google cloud and you basically write a command like 'give me a ubuntu 18 instance with username password foo/bar' and it instantly copies all the relevant data into it [18:34] so i assume all these cloud providers either use cloud-init or else have something themselves [18:37] johnjaye: yes the vast majority of cloud providers can or do use cloud-init (I think GCE had some alternative system in the past, not sure if it is still used) [18:37] so when you provision a Linux instance/VM on AWS, GCE, Azure, etc you give it user-data for that VM [19:44] falcojr: I lost a day to migraine [19:45] :( Migraines suck [20:03] I think it might have been just (lack of) caffeine induced, but it took almost a full day, and did not respond to ibuprofen. I've also started mapping them, to see if there's a pattern, cuz I feel that since i went thru Covid it's become a monthly recurrence [20:40] falcojr: will need fresher head to go fixing all those test failures when moving the ifconfig invocation into __init__ [20:41] but, I think that will also make it a good opportunity to extend tests to fit these new code paths [21:03] falcojr: i really need to start looking into TypedDict… it seems like it would solve a lot of problems… a lot of problems i have created for myself. [21:06] oh, i … went too far… [21:06] def is_physical(self) -> bool: [21:06] # OpenBSD makes this very easy: [21:06] return "egress" in self.groups [21:06] return self.groups == [] and self.media and "Ethernet" in self.media [21:06] This isn't erlang… [21:11] falcojr: absolutely no idea how to do this: https://github.com/canonical/cloud-init/pull/1779#discussion_r999877423 (without ruining typing) [21:11] -ubottu:#cloud-init- Pull 1779 in canonical/cloud-init "Net: add BSD ifconfig(8) parser" [Open] [21:46] meena: sorry, was a suggestion. If it works better for you to keep it as-is, that's fine [21:47] also, IIRC, TypedDict isn't supported on 3.6 which is still cloud-init's minimum version [21:47] falcojr: if you initialize dev = None at the top, it becomes Optional[Ifstate] and a lot more complicated [21:47] aye… [21:48] TypeDict is in the codebase already [21:48] I added it [21:48] I think it's available, but limited in what syntax you can use iirc [21:48] holman: you added a version gate I think...so I don't think I want to keep doing that everywhere [21:49] and now, to break some tests [21:49] and then goto bed. [21:49] oh you're right [22:03] okay, so, basically, now i need to mock every creation of a BSD mock distro, with a test appropriate output of subp([ifconfig -a]) [22:11] yeah, i don't think I'm getting any fresher ideas [22:11] Good night folks o/~ [22:23] weird… make check fails on my laptop, but not on Travis?