=== Guest44454 is now known as ice10001 [03:35] Hi all, anyone able to help with adding repositories (apt) to my custom user-data file, & updating, then installing latest software? [14:30] ice10001: hello, did you see/test the issue blackboxsw pointed out yesterday? [14:32] holmanb: re the Alpine lxc chat the other day, you are using lxc (container) rather than lxd (vm), right? I find the current lxc/lxd situation confusing due to the somewhat interchangable use of the 2 terms [14:32] minimal: I find it just as confusing tbh - I was using them interchangably, since the lxc command can by used to initialize both iirc [14:33] minimal: but yes, I ususually use it for containers, only vms occasionally with lx[cd] [14:33] I'm learning cloud-init and am having some confusing on the difference of /etc/cloud.cfg and the files in /etc/cloud.cfg.d . Does the /etc/cloud.cfg define which modules to run; and then the details (parameters) are defined in individual files in cloud.cfg.d ? It seems when the system boot it says it cannot find anything to do; but I have multiple files in /etc/cloud.cfg.d and have also tried concating these files into /etc/cloud/clooud.c [14:33] holmanb: yeah, from a cloud-init perspective it seems that LXD (vm) uses LXD datasource, whereas lxc (container) uses NoCloud datasource [14:35] minimal: I think lxd datasource supports both [14:35] amessyroom: generally you specify "what to do" in the user-data / meta-data / network-config rather than in those files [14:38] hmmm. but can user data be pre-created into the image, rather than pasted into a gui dialogue box i.e. azure . I'm trying to make a gold image that will build swap; register rh; update packages; and don't want to paste commands or put it in a file and have to pass it as a parameter. [14:39] i've not used user data; but just read there is a user-data area in /var/lib/cloud/seed//user-data so being azure will be my datasource I guess I can put things there ? [14:41] amessyroom: yes, seeds files are AFAIK a way to achieve what you want [14:41] from https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html?highlight=seed#what-is-instance-data "cloud-config seed files in the booted cloud image or distribution" [14:45] thanks. i'll give that a try. kinda confusing it seems you have multiple ways to do things but user-data seems to be the most used; trying to follow microsoft azure docs and have find that although helpful don't seem to have everything you need to understand to implement :-( [14:52] amessyroom: the reason for multiple ways is to provide flexibility. The "normal" method is user user-data which you provide via the cloud provider (UI/API/etc) when an instance/VM is created [14:52] the files in /etc/cloud.cfg and /etc/cloud.cfg.d are generally for enabling/disabling c-i modules and other generate setup, not for providing data to them [14:53] s/generate/general/ [15:03] minimal and holmanb: descriptions here might be helpful: https://linuxcontainers.org/ [15:03] in particular, "LXC provides the basic functionality used under the hood by LXD. However, it should not be confused with the lxc CLI client tool provided by LXD." [15:04] so any `lxc ` is actually using LXD (which under the hood is using LXC)...clear as mud, right? [15:12] falcojr: thanks :) [16:51] Hi there [16:51] could someone help me with an issue? [16:53] I know that in cloud-config I can refer to gpg url for yum with: gpgkey: [16:53] and that works [16:53] but ... how do I do it for apt? [16:54] I've tried with gpgkey: ..., and also with key_url: ... and it failed both times [16:54] this is my apt section on #cloud-config [16:55] apt: [16:55] sources: [16:55] python3: [16:55] - source: "ppa:deadsnakes/ppa" [16:55] terraform: [16:55] source: "deb [arch=amd64] https://apt.releases.hashicorp.com $RELEASE main" [16:55] file: /etc/apt/sources.list.d/hashicorp.list [16:55] gpgcheck: true [16:55] gpgkey: https://apt.releases.hashicorp.com/gpg [16:55] what am I doing wrong? or what would be the alternative?, please [17:25] Gordon85: what's the terraform key for? I assume that is one of your problems [17:28] ah, nvm that's the key name for a repo [17:53] Gordon85: Per the docs, gpgcheck and gpgkey are not valid keys for the apt module: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure [18:03] also the url you listed is just a gpg keyfile, I think the apt repo will require a keyserver url and keyid/fingerprint - the examples here might be a good starting point for what you're trying to do: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#additional-apt-configuration-and-repositories [18:24] Thank you holmanb I appreciate you taking the time to reply. [18:24] I did know the url was a gpg keyfile, but I thought cloud-init would just download it and use it (I didn't understand the whole inner workings behind gpgkey. I know that is the way it works for Yum, gpgkey can point ot a file or even a url) [18:24] Gordon85: alternative to a keyserver lookup, you can specify the key right in your config [18:25] thanks again, I'll check that part of the documentation (I didn't think to check the modules. The examples ... don't work that well for me, I did try keyserver, but ... I might have done something wrong because it didn't work) [18:51] looks like one minor error on our last focal integration test run now that the PPA build our daily recipe. https://github.com/canonical/cloud-init/pull/1420 for a minor integration test fix to clean up jenkins state [18:51] Pull 1420 in canonical/cloud-init "tests: verify_ordered_items fallback to re.escape if needed" [Open] [19:47] falcojr: I can't recall if you said you were working on an upstart related issue today or not. In the interest of cleaning house I started pulling together a "drop upstart stuff" PR https://github.com/canonical/cloud-init/pull/1421 [19:47] Pull 1421 in canonical/cloud-init "upstart: drop vestigial support for upstart" [Open]