| === tds1 is now known as tds | ||
| === cpaelzer__ is now known as cpaelzer | ||
| === tds3 is now known as tds | ||
| Odd_Bloke | Gaffel: Your paste appears to have expired, it's 404ing. | 14:04 |
|---|---|---|
| Gaffel | Odd_Bloke, I uploaded it again: https://paste.centos.org/view/1077fa4e | 14:24 |
| Gaffel | I'm unable to log in through both the TTY and SSH. The passwords have no effect. The file is literally "user-data" but nothing I type in that works. It only likes "meta-data". | 14:27 |
| Odd_Bloke | Gaffel: I don't have time to dig into this too much right now, but line 17 appears to be indented by an additional line. | 14:28 |
| Odd_Bloke | That might be causing the password setting to fail? | 14:28 |
| Gaffel | That's weird. I don't see that on my system. I pasted it manually. I'll check if there's no indentation issues in the file. | 14:29 |
| Gaffel | There are no tabs. That must haven't happend when I pasted. | 14:30 |
| Gaffel | I cut away the "users" stuff and only kept the chpasswd and ssh_authorized_keys. Now it lets me log in. :| | 14:41 |
| Gaffel | It uses cloud-init 18.5 | 14:42 |
| Gaffel | How can I test user-data since it won't let me access anything until now when the things I want to test has been removed? | 14:44 |
| powersj | Gaffel, we have a couple of ways documented via LXD and Mulitpass in addition to validating your YAML: https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-debug-my-user-data | 14:45 |
| powersj | I would at least try the devel schema command | 14:45 |
| powersj | not everything has schema, but it is worth a try | 14:46 |
| ananke | Gaffel: you also may want to start with something simpler: don't add additional users, just set password & keys for the default one | 14:47 |
| ananke | Gaffel: is this in ec2? | 14:48 |
| Gaffel | It's just local, I just want to test cloud-init, so you can use images without modifying them | 14:49 |
| Gaffel | It looks like it doesn't like my "sudo" string. | 14:49 |
| Gaffel | powersj, thanks for the tip. I thought that this was valid YAML but it seems to have issues. :/ | 14:49 |
| ananke | multipass has a few issues though with cloud-init | 14:51 |
| ananke | although your configs are simple enough they shouldn't be impacted by that. namely jinja2 templates | 14:52 |
| Gaffel | It works now. Thanks for the help! :] (now I just need to fix the things I actually wanted to try from the beginning) | 14:59 |
| Odd_Bloke | I'm still waiting for review on one of my cleanup PRs from last week: https://github.com/canonical/cloud-init/pull/283 | 15:30 |
| ananke | uhmm, is cloud-init.service supposed to be enabled or is it handled via other means? Wonder if my kali linux issue is related to the following: | 15:30 |
| ananke | root@kali:/etc/cloud# systemctl status cloud-config.service | 15:30 |
| ananke | ● cloud-config.service - Apply the settings specified in cloud-config | 15:30 |
| ananke | Loaded: loaded (/lib/systemd/system/cloud-config.service; disabled; vendor preset: disabled) | 15:30 |
| === tds2 is now known as tds | ||
| Odd_Bloke | ananke: All the units should be enabled together, either explicitly on installation or by cloud-init.generator (if it's been installed). | 15:32 |
| Odd_Bloke | rharper: We forgot to assign PRs in our daily meeting, but there's only one pending assignment, so I've just put your face on https://github.com/canonical/cloud-init/pull/289 | 15:33 |
| ananke | makes me think that Kali people mangled cloud-init installation | 15:35 |
| Odd_Bloke | It's certainly a possibility. | 15:37 |
| rharper | Odd_Bloke: ok | 15:48 |
| Odd_Bloke | blackboxsw: When you merged #288, the merge commit message ended up truncated at the first comma. Don't know how that happened, just a heads-up to keep an eye out for it. | 16:25 |
| blackboxsw | Odd_Bloke: thanks, yeah that's strange. and probably my end. Odd_Bloke rharper when we are squash merging are folks redacting the per-commit messages that github appends to the original PR description? | 16:26 |
| blackboxsw | for instance, if I have 10 commits in my squashed PR, github adds one line preceded by an asterisk for each additional commit | 16:26 |
| blackboxsw | in cloud-init's launchpad world, our squash merge would only use the branch description or top-most commit message as the squashed commit | 16:27 |
| Odd_Bloke | I have been removing any that don't add useful information. | 16:27 |
| Odd_Bloke | Like "* typo fix" doesn't help anyone. | 16:27 |
| blackboxsw | +1 Odd_Bloke, I generally have been doing the same. | 16:28 |
| blackboxsw | I think I just botched 288 | 16:28 |
| Odd_Bloke | But "* Fix the behaviour of Spam.eggs() when "ham" is passed" is useful for someone ending up at the squash commit via blame. | 16:28 |
| ananke | hmm, so it appears that Kali AMI has both cloud-config.service and cloud-final.service disabled by default. that doesn't make sense | 16:33 |
| blackboxsw | so, rharper I guess we have https://github.com/canonical/cloud-init/pull/267 then for Focal. and Odd_Bloke or rharper more jsonschema coverage to help folks w/ malformed user-data https://github.com/canonical/cloud-init/pull/152 | 17:05 |
| rharper | ananke: saw you update, will look at the data later. w.r.t the services, they should be 'vendor preset: enabled' | 17:06 |
| ananke | rharper: makes me wonder if kali linux folks have done some rudimentary setup required by amazon, and disabled what they didn't think was necessary. I've opened a bug with them as well: https://bugs.kali.org/view.php?id=6239 | 17:10 |
| ananke | now I need to figure out if I can fix this on first boot for cloud-init status --wait to function, or would it require another reboot | 17:11 |
| rharper | ananke: something that might work is a bootcmd which ran 'systemctl enable cloud-config.service; systemctl enable cloud-final.service' | 17:50 |
| ananke | rharper: funny enough, that's exactly what I'm trying to test now. I was also going to put in 'systemctl start' for both of them, or is that not necessary at that stage? | 17:53 |
| ananke | problem is that the first time cloud-config.service starts it fails, but then starting it the second time works | 17:54 |
| ananke | this is the error, I think I'll have to fix it before I can try the other stuff: http://dpaste.com/37R31X6 | 17:56 |
| Odd_Bloke | ananke: That looks like a misconfigured /etc/cloud/cloud.cfg{,.d/*}. | 17:58 |
| ananke | it appears to break on 'security' key, and the only place that word appears is in /etc/cloud/templates/sources.list.ubuntu.tmpl | 17:59 |
| ananke | and templates/sources.list.debian.tmpl | 17:59 |
| Odd_Bloke | ananke: My guess is that you're missing something like https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L172-L196 | 18:00 |
| Odd_Bloke | Or, alternatively, "apt-configure" shouldn't be configured to run, if Kali isn't a Debian derivative. | 18:00 |
| ananke | it's debian alternative, but I wonder if they don't have 'security' repo. Here's their /etc/cloud/cloud.cfg: http://dpaste.com/2DM65Q3 | 18:01 |
| Odd_Bloke | Yeah, I was about to say that yet another alternative is that cc_apt_configure needs to learn that security mirrors are not universal. | 18:02 |
| Odd_Bloke | But if you want something that doesn't require cloud-init code changes, then replicating that final line with s/primary/security/ might do it. | 18:03 |
| ananke | for rolling release distros that may be the case | 18:03 |
| ananke | Odd_Bloke: thank you, that's a great idea | 18:03 |
| Odd_Bloke | (It should definitely get you past the KeyError, I'm not sure if apt will warn you about duplicate sources, though.) | 18:05 |
| ananke | I'll test it on this instance, after I remove the proper semaphore. in theory this section of cloud.cfg could be overwritten by a file in /etc/cloud.cfg.d/myfile.cfg, right? | 18:06 |
| Odd_Bloke | Yes, though you have to replace the entire value of top-level keys. So you'd need to replicate the entire `system_info:` dict in there, and then make your changes to that. | 18:07 |
| Odd_Bloke | s/dict/mapping/, let's not confuse YAML and Python terms. | 18:07 |
| ananke | k. I was wondering about that. I'm already dropping in a file with partial system_info: set of keys, including default_user. Do I have to copy the _entire_ default system_info: section? | 18:11 |
| rharper | ananke: depends on what you're changing; dict merging rules will apply, so the last config will clobber previous values; | 18:13 |
| rharper | ananke: I don't think you want to start them; they just need to be enabled ... and I updated the bug, the other issue is that /etc/cloud/cloud-init.target.wants did not have all 4 services added | 18:14 |
| ananke | rharper: I'm changing the default username and gecos field. looks like I could do: http://dpaste.com/094W28X | 18:14 |
| rharper | so combine all services enabled, and an updated .wants and systemd should run all 4 services ... and need to sort out if you're making it to network-online.target | 18:14 |
| rharper | you can modify the default users with 'users': top-level key instead of system config | 18:15 |
| rharper | https://cloudinit.readthedocs.io/en/latest/topics/examples.html | 18:15 |
| ananke | ohh, interesting. thank you. not sure how we arrived at system config for the default users, perhaps some old examples | 18:15 |
| ananke | rharper: I was under the impression that 'users' provided ability to add additional users, but to change the username/gecos of the default we had to override it with system config | 18:17 |
| rharper | sure | 18:17 |
| rharper | unless you want to keep the distro default user and modify it; in your case you're changing the name anyhow, so users: [{'name': 'student', 'gcos': 'Cyber Range Student'}] will do what you want, making 'student' the default user, | 18:19 |
| rharper | IIUC | 18:19 |
| rharper | if you wanted both, you have users: ['default', {'name': 'student'}] ... | 18:19 |
| rharper | but I'm guessing you want the former | 18:20 |
| ananke | in my tests with ubuntu 18.04 it seemed to add a new user, rather than override the default one | 18:20 |
| rharper | hrm, | 18:21 |
| ananke | and regarding earlier comment about cloud-init.target.wants, looks like I had to also enable cloud-init-local.service. | 18:23 |
| ananke | so lesson learned, simply enabling cloud-config.service and cloud-final.service via bootcmd didn't seem to be sufficient, I had to ssh in and start them. wonder if reloading systemd would help | 18:43 |
| ananke | it may be too late in the boot process | 18:43 |
| rharper | ananke: so, since they weren't enabled or included in the cloud-init.target.wants, when cloud-init systemd generator runs it does not pull in all of the cloud-init units; if you are making changes in early boot, you will also need to: 1) systemctl daemon-reload 2) likely need to run systemctl start --no-block <service name> ;;; but I'm not sure if that will attempt to run the job righ t away or if it will wait for the right time to start ... | 18:57 |
| rharper | ananke: you really need modifications to the base image; I suspect your bug against kali itself would be where they'd fix the install of cloud-init correctly | 18:58 |
| ananke | rharper: thanks for the explanation. Yes, the problem needs to be addressed in the base image. I'm suspecting whoever is making that AMI wasn't too familiar with cloud init. I'll pass everything I find to the bug I have open with Kali | 19:01 |
| ananke | with that in mind, our goal is to take a base image, adjust it as needed for our purposes via automated means (packer + cloud init + scripts) and create a new image. So I'm creating a temporary band-aid solution here | 19:02 |
| rharper | ananke: great. | 19:04 |
| rharper | does packer let you run scripts on the image before booting it ? | 19:04 |
| ananke | rharper: yes and no. since the source is an existing AMI, the only thing we can pass is user-data with cloud-init specific items | 19:06 |
| ananke | so it's like a chicken & egg problem. I have to fix cloud-init via cloud-init :) | 19:06 |
| Odd_Bloke | rharper: blackboxsw: https://github.com/canonical/cloud-init/pull/291 <-- the mirror URL substitution PR | 19:09 |
| rharper | ananke: I wonder if you used the virtualbox image, convert it to raw or qcow2 format; then you can loopmount it and make changes | 19:09 |
| ananke | the basic steps are: 1) packer creates a new ec2 instance from a source AMI, and passes it user-data, 2) the very first 'provisioner' we have configured with packer is 'cloud-init status --wait'. packer connects via ssh as soon as sshd is available and runs that. 3) we run various other scripts, including cloud-init configs/scripts | 19:09 |
| rharper | ananke: and then upload that as an AMI | 19:09 |
| Odd_Bloke | (Another small one will follow, to address the TODO called out inline.) | 19:09 |
| ananke | rharper: it was a thought, but we're trying hard to avoid that. it requires tons of additional work | 19:10 |
| rharper | ananke: ok, one other thought; once you're in; instead of just running cloud-init status --wait; you can drop the wait; and if you know what stage of cloud-init you are running (or looking to see if it's actively running) wait for the stage to complete and then manually run the following stages; cloud-init modules --mode=config; cloud-init modules --mode=final | 19:11 |
| rharper | you may be able to avoid "fixing" the original kali image to boot correctly and then you only need to apply proper fixes to the current image in your script (rather than bootcmds) | 19:12 |
| rharper | Odd_Bloke: ok | 19:12 |
| ananke | thanks! I'll try that | 19:13 |
| Odd_Bloke | rharper: Thanks for the initial comments, I've replied to them all. | 19:51 |
| ananke | success! https://gitlab.com/kalilinux/packages/base-files/-/compare/d5519cfc422157245bfec9d6d35271b1b810480b...09e4f2bbd27044a6cb274847400e646b1703ad5e | 20:48 |
| ananke | I also suggested added the workaround for security repository, so hopefully that will be added soon | 20:49 |
| rharper | ananke: nice! | 20:53 |
| ananke | all credit goes to you for finding various things. I should comment on the bug I have open with cloud-init and link my bug open with Kali | 20:53 |
| ananke | I haven't looked in the cloud-init code much, but for the security repository issue in kali would creating a new /etc/cloud/templates/sources.list.kali.tmpl without that key work, along with setting distro type to 'kali' under system_config key? | 21:01 |
| Odd_Bloke | rharper: I've updated the commit message; where would you suggest we document the change in behaviour other than that? | 21:04 |
| Odd_Bloke | (We don't really have release notes per se, right?) | 21:04 |
| rharper | Odd_Bloke: I was thinking in docs around apt templating ... maybe we don't have a section on that | 21:24 |
| rharper | maybe we don't | 21:25 |
| rick_h_ | pvt | 21:50 |
| rick_h_ | bah | 21:50 |
| Odd_Bloke | blackboxsw: rharper: A small design section on type annotations: https://github.com/canonical/cloud-init/pull/293 and a couple of small cleanup PRs: https://github.com/canonical/cloud-init/pull/292 https://github.com/canonical/cloud-init/pull/294 | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!