[00:38] does anyone have an example of passing in a directory with 9p like a home directory? [00:38] for some reason i can't find one anywhere [00:40] maybe these have to be defined in my virsh xml file instead. [02:09] https://pcocc.readthedocs.io/en/latest/manpages/man7/9pmount-tutorial.html [02:10] i'm confused, it looks like you can specify 9p mounts [02:10] though i didn't see it mentioned on https://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts [02:11] sudo mount -t 9p works [04:01] Hi @all, [04:02] Hi @all, I am trying to run a shell script using cloud-init, but unable to do so for an offline system [04:03] Will you please help me in this, thanks in advance. [06:26] Hi all, [06:27] I am trying to run a shell script using cloud-config for modifying a ubuntu-iso, but that is not working for me. Will you please help me in this [06:28] d [13:52] could PRs #1081, #1082, and #1083 be considered for the 21.4 release? they are each minor changes [13:52] Bug 1081 in zope-cmfplone (Ubuntu) "Can't install plone-site" [Medium, Invalid] https://launchpad.net/bugs/1081 [13:52] Bug 1083 in seahorse (Ubuntu) "encryption not included in nautilus" [Medium, Fix Released] https://launchpad.net/bugs/1083 [13:52] Bug 1082 in safecat (Ubuntu) "Can't execute safecat" [Medium, Fix Released] https://launchpad.net/bugs/1082 [13:53] hmm, the ubottu bot doesn't map references to cloud-init PRs [14:18] minimal: I'll try to get them in this week, though I'll probably have some questions on the PRs themselves [14:20] falcojr: no panic, if they don't make the release its not the end of the world :-) I've submitted these simple ones to reduce any potential impact on the release, I'll keep more complicated PRs until after the release [14:23] hey, so i'm trying to pass in a home directory from my host [14:23] is 9p the right thing to do that? I'm using kvm/libvirtd [14:24] i'm using a filesystem declaration like so https://clbin.com/tiuJ6 [14:25] this goes in my file so when i do "virsh -c qemu:///system define vm.xml" it is available [14:25] dngray: that's not really a cloud-init question though? more a libvirtd one [14:26] i've got a fairly simple cloud-init [14:26] https://clbin.com/Zm4EU [14:27] if i type "mount -t 9p dngray /home/dngray/somefolder" it does mount, so 9p is working [14:27] but i am actually just passing wanting to pass the home directories in [14:28] i figured "no_create_home" would be appropriate, as i don't want to create a homedirectory [14:28] well it is i'm trying to get cloud init to mount it on boot [14:29] what i am saying is i've verified it works when defining/mounting manually, but that's not really what i want, i want to pass in my home directory [14:29] so t hat when i spool up a new vm, my home directory is always the same [14:29] dngray: this is alpine, right? [14:29] the line that seems to be not working is [14:29] mounts: [14:29] - [ dngray, /home/dngray, 9p, 'trans=virtio,version=9p2000.L,msize=262144,nofail', '0', '0'] [14:30] dngray[m]1: if you can use modern host consider using virtiofsd instead of 9p [14:30] i can't find much documentation, on someone using 9p to mount their home directory inside a vm created with cloud-init [14:31] dngray[m]1: this is an Alpine VM, right? [14:31] https://virtio-fs.gitlab.io/ + https://libvirt.org/kbase/virtiofs.html if you want to look at virtiofsd [14:36] minimal: host is alpine, guest is archlinux [14:37] cpaelzer: oh maybe i shouldn't use 9p then. i just thought that was what i needed. [14:37] oh i was already doing that i think [14:38] except i didn't set [14:38] dngray[m]1: ok, so that probably rules out busybox mount command (on alpine by default busybox provides mount command which has some limitations) [14:38] dngray[m]1: it is quite similar to configure, but if the host is new enough to have all you need for virtiofsd then IMHO it is preferable [14:39] it certainly should be the host is alpine linux 3.14.2 [14:40] dngray[m]1: did you try manually doing "mount -t 9p dngray -o trans=virtio,version=9p2000.L,msize=262144,nofail /home/dngray/somefolder" to verify the full command that cloud-init will try [14:40] i didn't manually do the whole command no, i just did "mount -t 9p dngray /home/dngray/directory" [14:40] so maybe that's the issue. [14:40] i kinda copied that from somewhere else i guess i shouldn't have [14:41] i'll try to use virtiofsd though if that's newer and preferable [14:41] right, so perhaps the command is not correct in the first place... [14:41] quite possibly. [14:42] as for your earlier VLAN issue with alpine, I tried to point out to you earlier on IRC that cloud-init specifically depends on ifupdown-ng which has the VLAN support - speaking as the Alpine maintainer for the cloud-init package :-) [14:43] oh yeah, i fixed that one by installing ifupdown-ng [14:43] and removing the ifupdown, that actually fixed the issue, and yes cloud-init does depend on ifupdown-ng in alpinelinux [14:44] when you use ifupdown-ng you don't actually need the old "vlan" package, that has a script that must be included in ifupdown-ng [14:44] oh yeah, so basically what you said, i figured out haha by trying it [14:44] dngray[m]1: my point was you shouldn't have needed to install ifupdown-ng as cloud-init depends on it already [14:44] oh yeah for sure, but it was conflicting with the vlan package, so i had to remove that first [14:46] I'm guessing perhaps you had upgraded prior to then and maybe didn't do an "apk -a upgrade" to have an up-to-date deps list [14:47] maybe. [14:47] dngray[m]1: one last thing, if you are intending to build cloud-init enabled Alpine images you might be interested in my script for this: https://github.com/dermotbradley/create-alpine-disk-image [14:48] i'll take a look, because i might in the future [14:48] i certainly do like alpine linux, but sometimes i want to use arch [14:48] mostly when im so lazy i want rolling release lol [14:49] I'm welcome to any feedback to improve cloud-init on Alpine [14:52] falcojr: I just had a failure in Travis CI for PR #1084 and it doesn't look like its anything to do with my PR. [14:52] Bug 1084 in thunderbird (Ubuntu) "Turn on full headers or long To: list and there is no scroll bar" [Medium, Fix Released] https://launchpad.net/bugs/1084 [14:53] falcojr: seems to be a Sphinx issue [15:05] Hello 👋. I'm not sure that I'm in the right place but I have a question about cloud-init. [15:07] I want to update my hostname on EC2 (to the instance_id) by using jinja templating. It works well when I pass the template as a `user_data` but not at all when set as a file in `/etc/cloud/cloud.cfg.d/15_hostname.cfg`. I'm on Debian 10 Buster with cloud-init version 20.2 [15:08] mNantern: 20.2 should have jinja template support. Do you have example raw user_data (be careful if you have passwds in it) [15:08] BTW: this is the right place [15:09] Thanks :pra [15:09] The file: https://pastebin.com/25G4diBa [15:10] mNantern: you can see the user-data that cloud-init sees on the vm with: `sudo cloud-init query userdata` [15:11] ahh sorry, backing up, you tried provided that ## template: jinja in the file named `/etc/cloud/cloud.cfg.d/15_hostname.cfg ? [15:11] Yes ! I shouldn't have? [15:13] normally jinja template renderers are applied to user-data block which is provided to the system at launch time. I think it doesn't apply during rendering of the consolidated system config which is on disk in /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/*. I'm double checking that now though. I believe this is a desirable feature for cloud-init, but I think it isn't currently implemented. Again, I need to double check that now [15:13] to confirm [15:15] Thanks! According to the doc (https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data) it should have worked, no? "Both user-data scripts and #cloud-config data support jinja template rendering. When the first line of the provided user-data begins with, ## template: jinja cloud-init will use jinja to render that file. " [15:20] mNantern: correct, thought I think that needs to be clearer in docs. The files that are delivered in an image on disk are considered merged system config which basically sets opinionated image configuration defaults. `sudo cloud-init query merged_cfg` would show you on your system what the merged config from disk looks like. user-data though is a separate configuration blob that can contain #cloud-config or user-data scripts etc. [15:20] That user-data is assumed to override any existed merged_cfg config defaults, cloud instance meta-data or cloud instance vendor-data. [15:21] all said, the user-data processing handlers I think are the only ones that are jinja aware. We could extend the merged config handling from disk to be jinja template aware. but I don't think that is there yet. [15:23] Alright, thanks for the verification! I will use my config in user_data in this case ! [18:12] blackboxsw: another CI dep issue... https://github.com/canonical/cloud-init/pull/1085 [18:12] Pull 1085 in canonical/cloud-init "Add max version to docutils" [Open] [18:23] falcojr: I assume you mean https://github.com/canonical/cloud-init/pull/1084 [18:23] Pull 1084 in canonical/cloud-init "hosts.alpine.tmpl: rearrange the order of short and long hostnames" [Open] [18:35] minimal: yes, it's a fix for that [18:47] ok, thanks [19:53] does ssh_import_id work with modern cloud_init? [19:53] the examples claim it does but i cannot observe it working [20:19] Xe: it does. Do you get any errors in your /var/log/cloud-init.log ? How are you specifying it?