| holmanb | blackboxsw: I got some initial comments up on the A-D schema PR. More to come tomorrow | 00:11 |
|---|---|---|
| meena | somebody reminded me that i need to submit a fix from almost a year ago: https://bsd.network/@brd/107678887598348834 / https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254339 | 08:39 |
| ubottu | bugs.freebsd.org bug 254339 in Ports & Packages "net/cloud-init: fix modifying rc.conf in cc_salt_minion" [Affects Only Me, Open] | 08:39 |
| === raekye2 is now known as raekye | ||
| holmanb | meena: Do you know of any docs describing running cloud-init with freebsd? I wouldn't know how to test such a PR. | 16:22 |
| meena | holmanb: you install it, and enable the service | 19:43 |
| meena | oh, and enable logging, or else the whole thing is going to be useless | 19:44 |
| meena | pkg install net/cloud-init | 19:45 |
| meena | sysrc cloudinit_enable="YES" | 19:45 |
| meena | in /usr/local/etc/cloud-init/ subdir make it so the logging config is included, so you're not flying blind | 19:48 |
| holmanb | meena: thanks! | 19:55 |
| blackboxsw | holmanb: I mentioned at standup today as far as setup of AWS Nitro-based systems with IPv6 IMDS I followed this guide (+ an initial pycloudlib Ec2 instance launch with dual-stack via ec2.get_or_create_vpc() call). https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/ | 21:44 |
| blackboxsw | I'm now able to confirm access to Ec2's IPv6 IMDS on my end. will run through a couple of tests locally and see if I can't shape up a PR for pycloudlib to make this easier. Right now to get access to IPv6 only I'm doing (probably a silly thing) ssh IPv4 into my dual-stack instance as a bastion host that can then ssh into the IPv6 only instance. | 21:45 |
| holmanb | blackboxsw: thanks for the ptr | 22:40 |
| blackboxsw | what remains to be understood is how I can not seem to scp into the instance, but can ssh in. | 22:42 |
| echeadle | I am trying to use cloud-init on Ubuntu server 21.10. I am using packer. I start the process and watch the progress on a virtualbox display. The graphical installer always runs and stops the process. This did not happen on 20.04. Is there an easy way to disable the graphical installer so cloud-init can finish? | 22:56 |
| blackboxsw | one interesting "cost" I'm seeing on these systems with Nitro IPv6 IMDS is a really slow crawl of metadata.. IPv6(+03.58600s) versus ipv4(+00.19400s) | 22:57 |
| holmanb | @blackboxsw: are you using a commit with ipv4 before ipv6? | 22:59 |
| blackboxsw | holmanb: no I was just trying to reorder ipv6 first intentionally to see how it'd behave | 22:59 |
| holmanb | ahh, huh | 22:59 |
| holmanb | interesting | 22:59 |
| blackboxsw | yeah holmanb not a logic problem in your implementation, but an IMDS IPv6 implementation prob I think | 23:00 |
| holmanb | curious | 23:00 |
| holmanb | curious if aws devs are aware of that | 23:01 |
| blackboxsw | echeadle: thanks for the question, I'm presuming you might be using Ubuntu server live iso maybe which is subiquity mased? Can you walk us through steps to reproduce the problem? | 23:01 |
| holmanb | 3.5s is significant | 23:01 |
| blackboxsw | s/subiquity mased/subiquity-based installer ISOs/ ? | 23:01 |
| blackboxsw | holmanb: yeah | 23:01 |
| blackboxsw | holmanb: yeah I need to get more data on that to see where the hangup is. it might be misconfiguration of routes not sure. haven't gotten more that a high-level smell there so far | 23:02 |
| echeadle | Sorry, yes it is the live server: https://releases.ubuntu.com/21.10/ubuntu-21.10-live-server-amd64.iso" | 23:02 |
| echeadle | In the boot_command I have "autoinstall ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ | 23:03 |
| minimal | blackboxsw: on a related IPv6 note, the fallback DHCP in cloud-init is IPv4 only currently | 23:04 |
| blackboxsw | echeadle: for a "headless" deployment you might want to use stock ubuntu server images (not server-live ISOs): https://cloud-images.ubuntu.com/impish/current/ | 23:04 |
| echeadle | It seems to find the user-data file and seems to run. But the ubuntu installer always runs after cloud-init runs. On 20.04 things rand fine | 23:04 |
| echeadle | Ok thanks. I am new to Ubuntu and in the examples I was following, they used the live server. | 23:05 |
| echeadle | I appreciate the help. | 23:06 |
| blackboxsw | echeadle: somewhat related, I think some of the interactions with cloud-init and server-live images are not exactly desirable for folks trying to roll their own images. See comment here for details | 23:06 |
| blackboxsw | echeadle: https://bugs.launchpad.net/subiquity/+bug/1958377/comments/11 | 23:06 |
| ubottu | Launchpad bug 1958377 in cloud-init (Ubuntu) "cloud-init does not apply network configuration from NoCloud resource" [Undecided, Incomplete] | 23:06 |
| echeadle | fantastic | 23:06 |
| blackboxsw | echeadle: to better educate me, are you following any public packer procedure/docs that you could reference for us? | 23:06 |
| blackboxsw | then I can better understand use-cases folks run into | 23:07 |
| echeadle | I started with Jeff Geerling's example repo found on github at geerlingguy/packer-boxes. | 23:09 |
| echeadle | https://imagineer.in/blog/packer-build-for-ubuntu-20-04/ | 23:09 |
| echeadle | https://github.com/Praseetha-KR/packer-ubuntu | 23:09 |
| blackboxsw | minimal: +1 and yes thanks, I'm going through the paces of exercising holmanb's https://github.com/canonical/cloud-init/pull/1160 | 23:09 |
| ubottu | Pull 1160 in canonical/cloud-init "Add ec2 IPv6 IMDS Support (SC-336)" [Open] | 23:09 |
| echeadle | https://www.golinuxcloud.com/generate-user-data-file-ubuntu-20-04/ | 23:10 |
| blackboxsw | ... per ec2/ipv6: and testing our failure paths, including our dhcp4-only sandboxed dhclient action on an IPv6 only box. some rough edges for us to understand/sort there | 23:10 |
| blackboxsw | thanks echeadle | 23:10 |
| echeadle | were three url's I found. Then just looking around stackoverflow and comments in askubunty | 23:10 |
| minimal | blackboxsw: yeah I know. I was recently trying to do IPv6-only with NoCloud via seed-urls and hit the problem of no IPv6 DHCP which defeated the IPv6-only aspect | 23:11 |
| blackboxsw | minimal: yeah I totally recall seeing your conversation here back and forth on that. That is definitely a gap we hope to shore up in the short term here. | 23:12 |
| * blackboxsw needs to re-read that in logs again for context | 23:12 | |
| minimal | blackboxsw: it was to do with there (obviously) being no way to provide network-config and so the fallback kicked in | 23:13 |
| minimal | blackboxsw: unrelated question: would there be any object to writing cloud-init code that extracts data from /etc/shadow? I was going to write a PR for the issue I flagged a while ago about needing to prefix user passwords with a "*" rather than using the lock_passwd option but obviously code cannot prefix an existing hashed password without accessing /etc/shadow | 23:15 |
| minimal | s/object/objection/ | 23:15 |
| blackboxsw | ahh, ok. I was hoping we can grow both dhcp4/6 support for fallback as well as EphemeralDHCPv4/EphemeralDHCPv6 for pre-networking discovery | 23:15 |
| blackboxsw | minimal: my security bells are going off. I vaguely recall seeing discussion on the /etc/shadow * character. but can't place the orig problem. this was due to passwd -l or something? | 23:20 |
| minimal | blackboxsw: its to do with openssh specifically - if a password is locked AND if PAM is not enabled for openssh then it refused to let key-based ssh work for that account | 23:22 |
| minimal | I assume most distros have PAM compiled for openssh and also the sshd_config has PAM enabled by default - in my case Alpine provided to distinct packages for openssh (with no PAM compiled in) and openssh-pam. Even with PAM support present someone may not wish to have it enabled for openssh. So I wanted to write functionality to prefix the user's password with "*", rather than "!" (which signifies a locked password) | 23:24 |
| minimal | however there seems to be no utility that will do the "*" prefix (unlike "passwd -l") and so I'd need to read /etc/shadow in order to get any existing hash to prefix it | 23:24 |
| blackboxsw | +1 and interesting condition there. I can't claim to understand the implications fully yet and I need to read some more man pages to feel super comfortable about the write direct to /etc/shadow. I'll take that question to our security team too to see if there are adverse concerns there. The only thing I'd like to understand more fully is whether there were a preferred utility that did that for you anyway outside of going | 23:26 |
| blackboxsw | into /etc/shadow directly to make that change (in case /etc/shadow format changed in the future etc ) | 23:26 |
| minimal | blackboxsw: that's my point, I have found no util that provides a means to prefix a hashed password | 23:28 |
| minimal | without this I have no means to "lock" an account to prevent password access (in general, not just via SSH) yet permit key-based SSH access to the same account | 23:29 |
| blackboxsw | minimal: +1, I've almost understood. Strange to me that a util doesn't exist to do this, but I admit being in the shallow end of the pool here. | 23:32 |
| minimal | blackboxsw: I guess there are not many use cases for wanted to add an arbitary prefix to a hashed password entry | 23:33 |
| minimal | usermod -p "*" is no use as that looses any existing password (and so this change can't be reverted later) | 23:35 |
| blackboxsw | I can promise to make sure the right eyes see a PR like this to vet any concerns and I'll spend a bit more time understanding the potential impact of direct modification. Given that chage and passwd, usermod and their related tools play around in that space too writing/updating the file is a fairly well trodden by these tools. I'll spend some time reading through man pages there to see if anything else that could | 23:38 |
| blackboxsw | suffice. | 23:38 |
| minimal | blackboxsw: I believe this is the relevant line in openssh: https://github.com/openssh/openssh-portable/blob/master/auth.c#L136 | 23:38 |
| minimal | note the "!options.use_pam" part - its treatment is condition on whether PAM is enabled/disabled | 23:39 |
| minimal | in general it seems that BSDs and Linux treat locked accounts differently - according to the Linux manpages a locked account is locked for password access, not for all access (i.e. SSH key). I think BSDs treat locked to mean locked in all/most cases | 23:40 |
| minimal | I sat down yesterday to write a c-i PR for this and then ti dawned on me that I didn't know of any util to add the "*" prefix....doh! | 23:41 |
| blackboxsw | ahh ok. I'm basically at your square one yesterday :) | 23:42 |
| blackboxsw | just trying to vet that it is not the case so I can understand context | 23:42 |
| minimal | blackboxsw: the openssh "problem" is easy to see - edit /etc/ssh/sshd_config and change UsePAM to "no", restart sshd, and then try and ssh in and see it refused | 23:46 |
| minimal | for an account with a locked password that is.... | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!