| === tds0 is now known as tds | ||
| === bashfulrobot_ is now known as bashfulrobot | ||
| === fyx_ is now known as fyx | ||
| === andrein_ is now known as andrein | ||
| === jdoss_ is now known as jdoss | ||
| === ]42[ is now known as [42] | ||
| unix_ | hi | 13:41 |
|---|---|---|
| unix_ | magyarul, english, deutsch? | 13:41 |
| unix_ | on smartos | 13:41 |
| unix_ | "customer_metadata": { | 13:41 |
| unix_ | "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0" | 13:42 |
| unix_ | } | 13:42 |
| unix_ | warum nicht funktioniert? | 13:42 |
| unix_ | host: smartos | 13:42 |
| unix_ | vm: centos | 13:43 |
| unix_ | [ 46.241951] cloud-init[1401]: 2021-03-04 13:53:21,339 - util.py[WARNING]: Failed running /var/lib/cloud/scripts/per-boot/01_smartos_vendor_data.sh [127] | 13:53 |
| unix_ | [ 46.249815] cloud-init[1401]: 2021-03-04 13:53:21,348 - cc_scripts_per_boot.py[WARNING]: Failed to run module scripts-per-boot (per-boot in /var/lib/cloud/scripts/per-boot) | 13:54 |
| unix_ | [ 46.254142] cloud-init[1401]: 2021-03-04 13:53:21,352 - util.py[WARNING]: Running module scripts-per-boot (<module 'cloudinit.config.cc_scripts_per_boot' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_scripts_per_boot.py'>) failed | 13:54 |
| unix_ | problem solved. | 14:08 |
| Odd_Bloke | Glad to hear you solved it. :) | 14:41 |
| unix_ | :D | 14:45 |
| Odd_Bloke | falcojr: https://github.com/canonical/cloud-init/pull/829 is ready for review; it's missing some testing docs, but is otherwise complete, I think. | 15:04 |
| Odd_Bloke | rharper: ^ is touching cloudinit.net, so of course your input would be great. :) | 15:04 |
| rharper | Odd_Bloke: sure | 15:09 |
| unix_ | little problem is that you add the gateway every time you reboot | 15:32 |
| unix_ | I only want to add it once | 15:32 |
| unix_ | currently only works in this form: | 15:36 |
| unix_ | "customer_metadata": { | 15:36 |
| unix_ | "user-script": "echo BOOTPROTO=none > /etc/sysconfig/network-scripts/ifcfg-net0 && echo DEVICE=net0 >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo HWADDR=92:9c:47:10:af:6b >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6ADDR=2001:4178:6:1416:62:116:187:84/64 >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo ONBOOT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0 | 15:36 |
| unix_ | && echo TYPE=Ethernet >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo USERCTL=no >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6_DEFAULTGW=2001:4178:6:1416::1 >> /etc/sysconfig/network-scripts/ifcfg-net0 && ifdown net0 && ifup net0" | 15:36 |
| unix_ | which is ugly but it works | 15:37 |
| Odd_Bloke | unix_: I'm not sure I understand what you mean by "add the gateway every time you reboot"? If it weren't added on every boot, it wouldn't be used, right? | 15:38 |
| unix_ | the first | 15:39 |
| unix_ | "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0" | 15:39 |
| unix_ | enter each time you restart.. | 15:39 |
| unix_ | then it looks like this: | 15:40 |
| unix_ | IPV6_DEFAULTGW=2001:4178:6:1416::1 | 15:40 |
| unix_ | IPV6_DEFAULTGW=2001:4178:6:1416::1 | 15:40 |
| unix_ | IPV6_DEFAULTGW=2001:4178:6:1416::1 | 15:40 |
| unix_ | etc | 15:40 |
| unix_ | version 2 already works fine, don't add it more than once, just too long | 15:42 |
| unix_ | there is definitely an easier method | 15:42 |
| Odd_Bloke | unix_: Aha, I think I understand: per-boot scripts are designed to run every boot; if you only want to configure that once per instance, then doing so in a per-instance script would perhaps be more appropriate? | 15:43 |
| unix_ | what is the difference between user-script and user-data? | 15:44 |
| unix_ | and bootcmd/runcmd? | 15:45 |
| Odd_Bloke | unix_: It looks like user-script is SmartOS-specific configuration, a shell script which is executed by cloud-init by default. | 15:56 |
| Odd_Bloke | bootcmd/runcmd would have to be specified as user-data, and the difference is when in the boot process they run; roughly: bootcmd runs early, runcmd runs late. | 15:57 |
| chillysurfer | question on cloud-init releases... when the upstream team creates a new release what effectively happens to the git repo? there's a git tag with just the version itself (e.g. `20.4.1`), and then there is an ubuntu/* tag for the release to ubuntu? | 16:01 |
| chillysurfer | but ignoring the ubuntu/* tag, the version tag release (standalone) is the indication in the git repo of a release? | 16:02 |
| unix_ | thx! | 16:07 |
| xscori | Hi! Have a q. about writing shh public key to a different location than the usual user's home dir. sshd_config in the system is looking for keys at /etc/ssh/keys/ | 16:23 |
| xscori | How can I tell cloud-init to use that location instead of inserting them into ~/.ssh/ ? | 16:23 |
| xscori | ssh* | 16:23 |
| stevenm | hey, so being new to cloud-init. Do most prepared images with cloud-init support... use the information given on the first boot and then never look again? | 16:26 |
| stevenm | it's like a pseudo iso that's mounted right? | 16:26 |
| meena | stevenm: unless something so significant in the hardware changes that the cloud decides to change your servers id, the most significant work happens on the first boot | 16:51 |
| meena | there are modules that run on every boot, tho | 16:51 |
| stevenm | well in this circumstance I would be the cloud myself (proxmox) | 16:52 |
| * meena has never built a cloud with proxmox | 16:53 | |
| stevenm | so I guess we'd set cloud-init options/files/etc against a VM.. boot it... then err 10 mins later? unset them all | 16:53 |
| stevenm | then in theory if it (the VM) ever tries to look at cloud-init data again (e.g. on reboot) it'd find nothing | 16:53 |
| meena | the data is cached on disk | 16:54 |
| meena | we fall back to the cache (if that's been merged lol) | 16:54 |
| stevenm | whose disk? within the VM's own disks? | 16:54 |
| meena | yes | 16:54 |
| meena | you give the VMs disks they can write to? | 16:55 |
| stevenm | oh i got the impression cloud-init could be used as a one time thing... e.g. setting an IP on first boot | 16:55 |
| stevenm | but you're saying the IP on subsequent boots would re-check what it's mean to be according to cloud-init? | 16:55 |
| meena | it does that, but there are scenarios where we might need to look at the data again | 16:56 |
| meena | like when someone forces a re-run | 16:56 |
| stevenm | i.e. the user of that VM forces their VM to re-check cloud-init data? | 16:56 |
| stevenm | defo unsetting it then lol | 16:57 |
| stevenm | we just want to use this little 'cloud-init' thing to make sure customer VM's are accessible on their choice of network on first boot *only* - the rest they can configure themselves | 16:57 |
| meena | there are good reasons to do that sometimes, tho i prefer to just blow away the VM and get a new one | 16:57 |
| stevenm | other minor things are admittedly unavoidable like default users/pass's etc... but we're aiming for minimum effort | 16:57 |
| meena | disk resize | 16:58 |
| stevenm | you mean filesystem resize? | 16:58 |
| meena | yeah | 16:58 |
| stevenm | well that'll be up to the VM in question I guess | 16:59 |
| meena | usually, you build images with the smallest size possible, you put it into the VM and then not it and cloud-init resizes the file systems | 16:59 |
| stevenm | "not it" ? | 17:00 |
| meena | Boot it | 17:00 |
| stevenm | ah yeah | 17:00 |
| stevenm | i mean I guess something things (cloud-init or not) might do that anyway | 17:01 |
| stevenm | e.g. like when you the raspberry-pi OS image on a microSD... on first boot it'll grow | 17:01 |
| meena | i recently learned freebsd does that on its own on first boot, so i should build my images with /first-boot touched and see who gets there first | 17:02 |
| Odd_Bloke | chillysurfer: Correct, those tags indicate the release commit. They should be signed and annotated, though I'm seeing that perhaps not all of them are currently. | 17:44 |
| Odd_Bloke | xscori: cloud-init doesn't handle non-default SSH key locations currently, unfortunately: it's complicated, and getting it wrong can have substantial security impacts. So your best bet is to use `write_files` or `runcmd` to arrange things as they should be. | 17:46 |
| Odd_Bloke | stevenm: cloud-init runs at every boot of cloud instances, to detect whether or not this is a new instance (as well as to perform any per-boot configuration supplied by the user). If it detects it is a new instance, it will re-run any per-instance actions, including network configuration. | 17:47 |
| Odd_Bloke | (If it doesn't run at every boot, then instances launched from images captured from instances will not behave correctly: they won't apply per-instance configuration despite the fact this is a new instance.) | 17:48 |
| Odd_Bloke | By default, though, cloud-init will not reconfigure networking on every boot. There are exceptions to this: e.g. EC2 Classic (i.e. pre-VPC) instances get a new MAC address at every boot, so configuration written for the previous MAC address will not apply on subsequent boots. | 17:49 |
| Odd_Bloke | It's worth noting that if you unset the metadata in the cloud, cloud-init may detect future boots as new boots. | 17:50 |
| Odd_Bloke | stevenm: https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination breaks down this behaviour in more detail. | 17:51 |
| === ijohnson is now known as ijohnson|lunch | ||
| === ijohnson|lunch is now known as ijohnson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!