2022-07-01 12:05:30 <blt> minimal: here ! so the error message I sent you was when I tried to manualy start chrony from the container just to test what's happen before investigating what can happen during the boot process, so I guess the first issue is this one and it is possible it is due to some lxc/lxd restriction which prevents adjtimex to run properly but I am not 100% sure
2022-07-01 12:10:54 <minimal> did you try searching online? https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1589780
2022-07-01 12:11:22 <minimal> looks like you shouldn't be using NTP inside a container - makes sense as the container gets its time from the host
2022-07-01 12:17:54 <blt> thanks that's the one I found but haven't read all the messages but yes it makes sense then!
2022-07-01 12:18:23 <blt> so everythin is working great, I just need to understand why sshd is not starting automatically during the boot
2022-07-01 12:20:06 <minimal> blt: is openssh installed already in your image? did you specify any user-data to configure it? did the cloud-init.log show anything releted to it? is the init.d service enabled for sshd?
2022-07-01 12:22:29 <blt> no error in cloud-init.log, but is is as simple as you just mentioned : init.d service is not enabled I thought it was the case for ssh on Alpine, I am wrong..I have a couple of idea through cloud-init but will read if there is already a function to handle init.d/service to start
2022-07-01 12:24:45 <minimal> blt: well I don't know how you are creating your image for LXC/LXD so it may not be enabled
2022-07-01 12:25:29 <blt> I am using one from cloud (lxc launch images:alpine/3.16/cloud)
2022-07-01 12:25:30 <minimal> cloud-init can start services but it will not enable init.d services
2022-07-01 12:25:56 <blt> which fonction you use to start services through cloud-init?
2022-07-01 12:26:41 <minimal> blt: that image is by the lxc people AFAIK
2022-07-01 12:27:56 <minimal> blt: not sure what you are asking. In your user-data if you use some SSH-related configuration then cloud-init may start or restart sshd. However it will not do the equivalent of "rc-add sshd default" to enable sshd at every boot
2022-07-01 12:33:25 <blt> I understand, so I may have issue as sshd is not starting automatically so I will investigate if I have something wrong in my user-data which prevents that to happen, starting it manually after container boots is working
2022-07-01 12:34:37 <minimal> blt: if the cloud-init ssh module is doing anything then you should see info from it in cloud-init.log
2022-07-01 12:35:12 <minimal> I have no yet looked at LXC's alpine image so I am unfamiliar what they have set up in it
2022-07-01 12:41:34 <blt> I see that : ssh_pwauth: 0 is not valid under any of the given schemas , so will double check my user-data
2022-07-01 12:49:04 <minimal> I think that "0" is treated the same as "False" by the yaml libraries
2022-07-01 13:31:12 <minimal> blt: I looks like the lxc image should have sshd enabled: https://github.com/lxc/lxc-ci/blob/master/images/alpine.yaml#L405
2022-07-01 14:01:13 <blt> strange as I am only adding simple parameters for ssh and I know it is working as if I start the service manualy I can connect with my keys, that's what I am using inside users:
2022-07-01 14:01:29 <blt>   ssh_authorized_keys:
2022-07-01 14:01:31 <blt>     - ${file("conf/blt.pub")}
2022-07-01 14:01:33 <blt> y
2022-07-01 14:01:51 <blt> (sorry for the y, it is obviously not in my conf)
2022-07-01 14:05:20 <minimal> that wouldn't cause cloud-init to restart sshd
2022-07-01 14:07:07 <blt> but I understood that sshd is supposed to start automaticaly, doesn't it ? you think something else needs to be added to cause the start ?
2022-07-01 14:07:23 <minimal> yes but nothing to do with cloud-init
2022-07-01 14:07:47 <minimal> I already shows you that the lxc alpine image is enabling sshd to start: https://github.com/lxc/lxc-ci/blob/master/images/alpine.yaml#L405
2022-07-01 14:08:24 <blt> yes I am on it, but I don't understand why it doesn't start
2022-07-01 14:08:26 <minimal> so what makes you think sshd is not started?
2022-07-01 14:09:07 <blt> because when I connect to the container it is on "stopped" state , if I service sshd start, all is good
2022-07-01 14:09:30 <minimal> so did it ever start (and then stopped for some reason) ?
2022-07-01 14:09:49 <minimal> have you checked logfiles in /var/log ?
2022-07-01 14:10:34 <minimal> is the sshd service enabled? "rc-status -a" and look for sshd
2022-07-01 14:12:40 <blt> in fact it is not in rc-update/rc-status, so it is like the ssh is even not asked to start, so it seems that this is coming from the cloud version of alpine..
2022-07-01 14:13:28 <minimal> blt: and I once again above pointed out that the lxc alpine cloud image does appear to setup sshd to start
2022-07-01 14:13:44 <blt> what would be the proper/best way to add that through cloud-init? through runcmd ? 
2022-07-01 14:14:01 <blt> yes I agree that's the reason why I don't understand why it doest start..
2022-07-01 14:14:11 <minimal> blt: maybe you should ask them?
2022-07-01 14:14:12 <blt> but let me paste the rc-status
2022-07-01 14:15:13 <blt> https://tpaste.us/6EBa 
2022-07-01 14:15:42 <blt> you think I should ask to lxc/lxd team ?
2022-07-01 14:16:38 <minimal> well it is their image
2022-07-01 14:18:38 <minimal> actually looking at their template:   types:
2022-07-01 14:18:38 <minimal>   - cloud
2022-07-01 14:18:38 <minimal>   - vm
2022-07-01 14:18:38 <minimal>   variants:
2022-07-01 14:19:00 <minimal> so that i guess is referring to LXD (type "vm"), rather than LXC
2022-07-01 14:19:23 <minimal> so it looks like their LXC image does not enable sshd
2022-07-01 14:20:34 <minimal> whereas they do add the openssh package (and its deps) to both LXC and LXC images
2022-07-01 14:20:57 <minimal> so the sshd program is there, its init.d service is only enabled for LXD and not for LXC it appears
2022-07-01 14:33:40 <blt> interesting thanks for your findings
2022-07-01 14:33:50 <blt> I am looking to the options from lxd
2022-07-01 14:34:16 <minimal> do you actually know what you want? lxc is a container, lxd is a VM
2022-07-01 14:35:03 <minimal> I guess they do not expect (most) people running lxc want to have a sshd running
2022-07-01 14:35:41 <blt> lxc definitely, and yes most would not have ssh but some will
2022-07-01 14:35:46 <blt> | alpine/3.16 (3 more)       | cf61ef2ccc71 | yes    | Alpine 3.16 amd64 (20220701_13:01) | x86_64       | CONTAINER       | 2.49MB   | Jul 1, 2022 at 12:00am (UTC)  |
2022-07-01 14:35:48 <blt> +----------------------------+--------------+--------+------------------------------------+--------------+-----------------+----------+-------------------------------+
2022-07-01 14:35:50 <blt> | alpine/3.16 (3 more)       | f00f2e0f548d | yes    | Alpine 3.16 amd64 (20220701_13:01) | x86_64       | VIRTUAL-MACHINE | 92.25MB  | Jul 1, 2022 at 12:00am (UTC)  |
2022-07-01 14:35:52 <blt> +----------------------------+--------------+--------+------------------------------------+--------------+-----------------+----------+-------------------------------+
2022-07-01 14:35:54 <blt> | alpine/3.16/cloud (1 more) | 3af22fead0c0 | yes    | Alpine 3.16 amd64 (20220629_13:21) | x86_64       | VIRTUAL-MACHINE | 121.88MB | Jun 29, 2022 at 12:00am (UTC) |
2022-07-01 14:35:56 <blt> +----------------------------+--------------+--------+------------------------------------+--------------+-----------------+----------+-------------------------------+
2022-07-01 14:35:58 <blt> | alpine/3.16/cloud (1 more) | 4fddbdceaf57 | yes    | Alpine 3.16 amd64 (20220629_13:21) | x86_64       | CONTAINER       | 21.33MB  | Jun 29, 2022 at 12:00am (UTC) |
2022-07-01 14:36:00 <blt> that's the options for 3.16
2022-07-01 14:36:14 <blt> for cloud based images indeed there is a VM and CONT versions
2022-07-01 14:36:30 <minimal> blt: ok, so if "some will" then they (like yourself) would need to enable sshd then
2022-07-01 14:36:38 <blt> will ask on the lxc channel just to by curiosity
2022-07-01 14:37:04 <blt> you just do a runcmd or there is a better way to do that ?
2022-07-01 14:37:25 <minimal> blt: actually thinking about it, the LXC container may not even have an init running to start services (I have not checked)
2022-07-01 14:38:54 <minimal> blt: hm, it must have an init (openrc) as you pasted "rc-status" output, doh!
2022-07-01 14:39:24 <minimal> yes you could use a "runcmd" or you could look at ssh settings in user-data
2022-07-01 14:40:11 <blt> yep init is here, I took a look on ssh settings but haven't find anything but perhaps I missed somethign
2022-07-01 14:40:42 <minimal> blt: didn't find anything about ssh? it all documented on the cloud-init docs site
2022-07-01 14:41:00 <blt> no no I meant nothing on ssh related to starting the service
2022-07-01 14:44:54 <minimal> ah, cloud-init only restarts sshd (after it makes sshd_config changes) if it is running, it doesn't start it if it is not
2022-07-01 14:46:30 <blt> ha that's the reason ! hum... so will do a runcmd, would be great to have cloud-init to manage services but I don't find anything like this
2022-07-01 14:47:09 <minimal> or create your own custom lxc image that does have sshd enabled....
2022-07-05 14:55:23 <tomalok> ncopa: i hear you've been looking for some NoCloud in TinyCloud?  https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests/24 - mostly untested at the moment, and doesn't support loading meta/user/vendor-data via kernel command line yet -- but mounting cidata/CIDATA volume code containing those files is there.
2022-07-05 15:01:48 <minimal> tomalok: interesting. re the kernel command line stuff, when I once tried that with cloud-init (from memory) it didn't work as expected as I think initramfs messed with it
2022-07-05 15:06:24 <tomalok> hm, will keep that in mind -- might be something to do to initramfs to allow that to pass... 
2022-07-05 15:08:04 <minimal> tomalok: I only tried it once and was probably 6 months ago so my memory is rusty, must find some time to test again
2022-07-05 15:08:58 <minimal> I "think" it might have been due to either ":" or "/" characters in a url
2022-07-05 15:10:47 <minimal> tomalok: I didn't see "network-config" support mentioned in your MR
2022-07-05 16:16:50 <ncopa> tomalok: very nice!
2022-07-05 17:39:25 <tomalok> minimal: first part is for grabbing the meta/user/vendor-data files from somewhere.  `imds` currently isn't called until the network is up -- so configuring nocloud-net via kernel command line to get network config info to reconfig the network may be a little tricky -- unless i'm misundestanding "network-config", in that case, more info please...
2022-07-05 17:39:25 <tomalok> :)
2022-07-05 17:40:39 <minimal> tomalok: a CIDATA fs/iso can contain network-config as well as meta-data and user-data
2022-07-05 17:43:03 <minimal> "imds" is a metadata server, NoCloud is used where there is no metadata server. It can however retrieve meta-data, user-data, and (I think) vendor-data via a specified seed URL, but that's a different use of NoCloud than it using a CIDATA location
2022-07-05 17:44:39 <minimal> so if you are using seed URLs then cloud-init will use DHCP to get a "temp" IP address, retrieve meta-data/user-data/vendor-data from the URL and then set the /etc/network/interfaces file (whether defaulting to DHCP or using network info embedded in meta-data content)
2022-07-05 19:57:55 <tomalok> the `imds` command in tiny cloud is for accessing the IMDS service -- whatever that happens to be -- for nocloud, that's the installed YAML files
2022-07-05 19:59:13 <tomalok> found the ref to network-config file in cloud-init  nocloud ref, will look closer later
2022-07-06 14:19:48 <tomalok> i think the first iteration of Tiny Cloud's nocloud support will simply be to get the files, put them in /var/lib/cloud, and be able to use the `imds` tool to get at their contents.  Right now Tiny Cloud only supports user-data `#!` scripts, and not `#cloud-config`, and network-config is kinda along that same line.  But I think network-config is
2022-07-06 14:19:48 <tomalok> certainly the target for the second round.
2022-07-06 14:25:10 <minimal> tomalok: and network config can be placed in meta-data file also ;-)
2022-07-06 15:16:42 <tomalok> and the user-data script could extract that data from the meta-data using the `imds` tool and do the right things  :)
2022-07-06 15:17:30 <tomalok> that'd be possible after the first iteration.
2022-07-15 23:12:53 <tomalok> ncopa: tiny-cloud-2.1.0_rc5 is now on edge -- hopefully i'll be able to build a "nocloud" image this weekend and run it through some tests
2022-07-18 20:28:33 <tomalok> ncopa: looks like i have some new cloud images to roll?  just 3.16.1 this time (or is there going to be any action on the older stables?)
2022-07-18 20:34:05 <ikke> 3.14.6 was released the other day
2022-07-18 20:34:28 <ikke> oh, no, that one is older
2022-07-18 20:51:45 <tomalok> fwiw, ikke, i made some progress on a the https://alpinelinux.org/cloud page revamp -- but then got distracted by other things, so for sure the javascript filtering isn't done yet.  but it looks pretty.
2022-07-20 04:20:31 <tomalok> looks like I'll be rolling 3.15.5 cloud images tomorrow (a bit late for tonight)
2022-07-28 01:36:58 <tomalok> currently a preview for the cloud page revamp is viewable at https://wwwdev.alpinelinux.org/cloud - this enables us to make the existing "cloud-init" AWS images more visible and can handle multiple clouds (and eventually image downloads, which is required for NoCloud) - fwiw
2022-07-28 01:36:58 <tomalok> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/52 is the pending merge.